Subject: Re: [sv-cc] [Fwd: Re: Version 2 of DPI LRM]
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Tue Mar 11 2003 - 17:03:35 PST
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 archive was generated by hypermail 2b28 : Tue Mar 11 2003 - 17:05:05 PST