Subject: Re: DirectC C-Layer: open arrays and abstract access - revised
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Fri Jan 10 2003 - 14:33:09 PST
> Francoise:
>
> thanks for the answers. See more comments in blue.
Again, my answers to Francoise's questions are interspersed with the relevant
excerpts.
Andrzej
> >========================================================================
> >Francoise:
> >#########
> > > Did you think about have a single function doing the queries for the
> > entire
> > > open array
> > > and returning the information in a single data structure rather than
> > having
> > > distinct functions?
> > > The reason for this being that the C user code may need it all anyway.
> > >
> > > example:
> > > int svcOpenArrayData(svcHandle, svcDim_p dimdata);
> > > where svcDim_p is a pointer to list of structures svcDim describing the
> > > array dimensions
> > > from right most range to left most range. That way there is no limitation
> > > on the topology
> > > of the open array.
> > >
> > > struct svcDim{
> > > int high, low, left, right, length;
> > > svcDim_p next;
> > > }
> >
> >
> >Who will allocate and de-allocate that structure (list)?
> >I'm afraid that it will be simply asking for a trouble (memory leaks).
> >
> >The simulator would allocate the structure list as only the simulator
> >knows the
> >number of dimensions. The structure list data would be valid until another
> >call
> to svcOpenArrayData. The C application is responsible to traverse the list
> immediately before another call to svcopenArrayData or copy that structure
"only the simulator knows the number of dimensions"
Function vcDimensions() provides the number of dimensions, so user
may allocate an array (or a list) herself.
Data structures dynamically allocated by a simulator and consumed by the user's
code are very prone to memory leaks. That's why I don't think this would be
a good idea. Simulator may attempt to free such list at the next call of
svcOpenArrayData(), but what if a list get corrupted?
Really, I don't see much benefits in providing such functionality.
> > > >Access to the actual representation
> > > >-----------------------------------
> >Francoise:
> >#########
> > > How do you use the generic pointer void * which is returned. How do you
> > > traverse the actual representation?
> > > Let's assume that we have an open array of SV unpacked structures ?
> > How do
> > > I retrieve the value of one element of that array?
> >
> >User has to cast a generic pointer.
> >See Example 3. In short:
> > MyType my_value = *(MyType *)svGetArrElemPtr1(h, i);
> >
> >I'm not sure I understand what you meant by "traversing the actual
> >representation".
>
> I think that the answer to my question is that the C code needs to know
> what is the internal representation.
Not necessary; at least not the user's code.
> If the generic pointer is a pointer to a value of a C
> compatible type, then the C code knows to interpret the layout because it
> is by definition compatible C compatible, C code can cast it to the C
> corresponding data type.
Right.
> If the generic pointer is a pointer to a SV type which is not C compatible
> (packed arrays) then the C code needs to know the vendor representation.
> Correct?
Actually, only the library code needs to know the vendor representation,
not the user's code.
Example:
SV:
extern void foo(input logic [127:0]);
extern void boo(input logic [127:0] i []); // open array of 128-bit
C:
#include "svc_bin.h"
/* one 128-bit packed vector */
void foo(svLogicPackedArr packed_vec_128_bit)
{
svLogicVec32 arr[VEC32_NEEDED(128)]; /* canonical representation */
svGetLogicVec32(arr, packed_vec_128_bit, 128);
...
}
/* open array of 128-bit packed vectors */
void boo(svHandle h)
{
int i;
svLogicVec32 arr[VEC32_NEEDED(128)]; /* canonical representation */
for (i = svLow(h, 1); i <= svHigh(h, 1); i++) {
svLogicPackedArr ptr = (svLogicPackedArr)svGetArrElemPtr1(h, i);
/* user need not know the vendor representation! */
svGetLogicVec32(arr, ptr, 128);
...
}
...
}
This archive was generated by hypermail 2b28 : Fri Jan 10 2003 - 14:33:48 PST