Subject: Re: [sv-cc] [Fwd: Re: Version 2 of DPI LRM]
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Tue Mar 11 2003 - 18:03:04 PST
> 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 : Tue Mar 11 2003 - 18:03:39 PST