Subject: RE: [sv-cc] [Fwd: Re: Version 2 of DPI LRM]
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Mar 12 2003 - 10:24:35 PST
Andrzej,
This is a great explanation you gave to John about source
compatability. I learned a few things that were not
obvious to me, mainly since I avoided the "deep think" about
the issue that you have been through.
To re-iterate the request John and I made in the meeting, I think
it is important that we more precisely define the bounds of source
compatability in the LRM. We should give specific examples of
common programming practices that would break compatability,
and outline the set of expectations the LRM places on users in
order to ensure source compatability.
The way the LRM is currently written, it appears that source
compatability is free (i.e. the term "guaranteed" is used in
places). But it's not - it is granted provided the user also
programs in a certain, constrained fashion. We need to be real
clear about this.
Would you agree to make some additions to the LRM on this matter?
Thanks and regards,
Doug
> -----Original Message-----
> From: Andrzej Litwiniuk [mailto:Andrzej.Litwiniuk@synopsys.com]
> Sent: Tuesday, March 11, 2003 6:03 PM
> To: Stickley, John
> Cc: sv-cc@server.eda.org
> Subject: Re: [sv-cc] [Fwd: Re: Version 2 of DPI LRM]
>
>
> > I was thinking more in terms of directly interpreting
> > the internals of the data object using knowledge of
> > vendor specific data types. At the end of your response
> > I think you agree that this would not be source compatable
> > among different vendors.
>
> Absolutely. We are on the same page here. And, frankly, that
> kind of application
> I also had in mind, among other applications. Nevertheless, I
> decided that
> vendors would figure out such uses and their non-portability
> as a consequence of
> dealing with internals, themselves.
>
> Andrzej
>
>
> > Andrzej Litwiniuk wrote:
> > > John,
> > >
> > > Here is my feedback to your feedback.
> > > In short, I understand your concerns, although I disagree
> with your conclusion.
> > >
> > >
> > >>--------------------------------------------
> > >>A.7.1 Overview - 3rd paragraph
> > >>
> > >>I'm a little confused by the wording of this. If applications
> > >>access packed arrays directly using implementation
> > >>specific representation, is it not also source compatiblity
> > >>that compromised as well ?
> > >
> > >
> > > Not necessary. It depends on what an application does.
> > >
> > > The phrase "access the packed arrays directly through
> pointers using
> > > implementation representation" is deliberately vague.
> > >
> > > For example, one may move values around without knowing
> their internal
> > > representation (copy, assign, write into a file or read
> from a file, etc.).
> > > Similarly, such values can be stored, hashed, retrieved
> without knowing
> > > their structure. For example, one may want to implement a
> queue of such
> > > values or a "cache" (hash table, search tree, etc).
> > > All that it takes is the size of the representation of a value.
> > > Functions svSizeOfLogicPackedArr(),
> svSizeOfBitPackedArr() may be used,
> > > and that way a binary compatibility may be achieved.
> > >
> > > Similarly, macros svSizeOfLogicPackedArr and svSizeOfBitPackedArr
> > > may be used to declare local variables of vendor-specific types.
> > > Such variables can be then used as a kind of black boxes;
> their actual
> > > definition is needed for compilation (and hence source
> level compatibility)
> > > but not for writing the code.
> > >
> > > An application may also co-operate with another
> application or a library,
> > > and interchange SV values via pointers. The actual
> implementation of that
> > > other application or a library may be vendor specific and
> not portable, but
> > > that will not compromise the portability of the first application.
> > >
> > > For example, a consortium of vendors may support a
> library of functions
> > > for bit manipulation (bit selects, part selects, etc.). A
> particular
> > > implementation of such library will not be portable,
> nevertheless the
> > > applications that use such library will be binary
> compatible with every
> > > simulator (assuming that simulator comes with a library).
> > >
> > >
> > >
> > >>Perhaps here we should make it clear that source compatability
> > >>is compromised in addition binary compatibility.
> > >
> > >
> > > Oh, well. Source and binary compatibility may be
> compromised but this
> > > is not inherent. It really depends on what the users do.
> > >
> > >
> > >
> > >
> > >>I understand that if all access is done using the access
> > >>functions in section 10 for individual elements then it is
> > >>still source compatible. But the wording of this implies
> > >>direct access of the implementation specific representation
> > >>without using any functions but rather vendor specific
> > >>data types used in implementation. Was that your intent here ?
> > >
> > >
> > > The intent here was that pointers allowed to handle
> vendor specific data types
> > > without the full knowledge of their representation.
> > >
> > > You are right, however, that if an application explicitly
> makes use of
> > > details of vendor specific data types, then it's not
> source level compatible.
> > > But this will be also true for any data types defined
> outside an application.
> > > I assumed that this would be pretty obvious.
> > >
> > >
> > >
> > > Andrzej
> >
> >
> > --
> >
> > 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.
> > __
> > ______ | \
> > ______________________/ \__ / \
> > \ H Dome ___/ |
> > John Stickley E | a __ ___/ / \____
> > Principal Engineer l | l | \ /
> > Verification Solutions Group | f | \/ ____
> > Mentor Graphics Corp. - MED C \ -- / /
> > 17 E. Cedar Place a \ __/ / /
> > Ramsey, NJ 07446 p | / ___/
> > | / /
> > mailto:John_Stickley@mentor.com \ /
> > Phone: (201)818-2585 \ /
> > ---------
> >
>
This archive was generated by hypermail 2b28 : Wed Mar 12 2003 - 10:25:24 PST