Subject: Re: [sv-cc] [Fwd: Re: Version 2 of DPI LRM]
From: Stickley, John (john_stickley@mentorg.com)
Date: Tue Mar 11 2003 - 17:17:13 PST
Andrzej,
OK, this makes more sense now.
I agree with all your points below about how
you can manipuate a vendor specific data object
as an aggregate without knowing it's specific
contents if you only know the size of the
aggregate. I also agree that as long as you
only do that, it can still be source compatible.
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.
-- johnS
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 - 17:23:53 PST