Subject: Re: pointers & handles
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Tue Jan 07 2003 - 14:02:18 PST
> From Andrzej.Litwiniuk@synopsys.com Tue Jan 7 12:33:06 2003
> From: "Andrzej Litwiniuk" <Andrzej.Litwiniuk@synopsys.com>
> Subject: Re: pointers & handles
> To: Kevin.Cameron@nsc.com
> cc: sv-cc@eda.org
>
> Kevin wrote:
> > I have no objection to individual implementations using pointers if they
> > can, however an interface that depends on it won't work in general.
>
> Why do you think so? What's wrong with the pointers?
>
Most simulators do some scattering and gathering of net data, i.e what looks
like an array of values to the user is actually an array of references to
slices of nets in other scopes, some of the drivers of those nets may be 0/1
(bit) others may be 0/1/X/Z. Some implementations copy value changes to a
local copy of the data that does look like what the user sees, others don't.
Data written to a signal is often written to a driver and not to the same
location as the signal value is read from, and driver structures are not
the same as signal value structures. Drivers may also only be associated
with parts of a larger structure rather than the whole too.
Generally it's not the sort of thing you want to hand the user a pointer to.
> > If the interface is specified such that all calls can be macro-definintions
> > then it should work either way.
>
> > Indirect:
> >
> > #define svcGetArrElemPtr2(my_value,MyType,h,i,j)\
> > NSCsvGetArrElemPtr2(&(my_value), h, i, j);
>
> Kevin,
>
> The interface may provide functions for the predefined types
> (int, shortreal, etc.) or predefined classes of types (packed bit/logic arrays),
> but =not= for all the possible user-defined types!
The type information is redundant if the function being called knows what type of
data is in the object being accessed. I.e. the function prototype for the above
would be:
bool NSCsvGetArrElemPtr2(void *,svHandle,int,int);
If I was worried about sizes I could redo it as:
bool NSCsvGetArrElemPtr2(void *,int,svHandle,int,int);
#define svcGetArrElemPtr2(my_value,MyType,h,i,j)\
NSCsvGetArrElemPtr2(&(my_value),sizeof(MyType), h, i, j);
- and check somewhere.
> Although it is possible to generate an access function for each user defined
> type, such approach seems impractical.
> Therefore no simulator can provide a function "NSCsvGetArrElemPtr2"
> for your private type "MyType".
But that applies to your apprach too (unless you're doing something fancy with
C++), i.e. you had:
my_value = *(MyType *)svGetArrElemPtr2(h, i, j);
which means nothing without an agreement between the user & simulator on MyType.
I think we both meant a simulator/vendor specific type.
> I don't see how it could be possible to provide access to an array element of
> arbitrary a type without resorting to pointers, if a predefined library
> is to be used.
Maybe, but the pointer doesn't need to be to the element, it can be to local data.
If you use macros that work either way, an optimizing compiler should be able to
give you much the same result.
>
> > NB: Macro definitions generally don't take "..." arguments.
>
> Right. So, macros won't do the trick either, will they?
They do, but you might have to specify more of them.
Ideally I would do this with C++ so I could use a single class/method definition
something like:
h->get2(&my_value,i,j);
h->put2(&my_value,i,j);
And I could use inlining/overloading to make it work fast or virtual functions
for abstract access. Macros would let me do that too:
#define svcGetArrElemPtr2(my_value,MyType,h,i,j)\
((NSChandle *)h)->GetArrElem2((void *)&(my_value),sizeof(MyType), i, j);
And of course you can just implement the macro as an actual call too for portable
code.
Kev.
PS: With C++ you should be able do a template array class for easier access,
something like:
svArray2D<VCStype> array(h);
VCStype data;
data = array[i][j]; // =/[] overloaded to do get above.
>
> Andrzej
>
>
This archive was generated by hypermail 2b28 : Tue Jan 07 2003 - 14:03:28 PST