Subject: Re: DirectC C-Layer: open arrays and abstract access - revised
From: Francoise Martinolle (fm@cadence.com)
Date: Fri Jan 10 2003 - 13:52:18 PST
Andrzej,
thanks for the answers. See more comments in blue.
At 02:03 PM 1/10/2003 -0500, Andrzej Litwiniuk wrote:
>My answers to Francoise's questions are interspersed with the relevant
>excerpts.
>
>Regards,
>Andrzej
>========================================================================
>
>
> > >Open array querying functions
> > >=============================
> > >
> > >These functions are modelled upon SV array querying functions, with
> > >the same semantics:
> > >
> > >/* h= handle to open array, d=dimension */
> > >
> > >/* For unpacked part */
> > >int svcUnpackedLeft(svcHandle h, int d);
> > >int svcUnpackedRight(svcHandle h, int d);
> > >int svcUnpackedLow(svcHandle h, int d);
> > >int svcUnpackedHigh(svcHandle h, int d);
> > >int svcUnpackedIncrement(svcHandle h, int d);
>
>
>Francoise: What does this function do?
>#########
>
>Pls. cf. LRM 16.3 "Array querying functions".
>Generally, svNAME corresponds to $NAME.
>
>So, vcsvcUnpackedIncrement(h,d) shall return 1 if vcUnpackedLeft(h,d) is
>greater
>than or equal to vcUnpackedRight(h,d), and -1 otherwise.
>okay I found the system task definitions in the SV3.0 draft Increment
>basically returns the direction of the range.
> > >int svcUnpackedLength(svcHandle h, int d);
>
>Francoise: Does this function returns the width of a given dimension?
>######### basically high - low +1?
>
>Yes.
>
>
>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
> > >int svcUnpackedDimensions(svcHandle h);
> > >
> > >/* For 1-dimensional packed part */
> > >int svcPackedLeft(svcHandle h);
> > > ....
>
>Francoise:
>#########
> > I don't see the need for both unpacked and packed queries functions, you
> > could make it so that if the dimension is 0, then the query could be
> > relative to the packed range.
>
>
>This actually seems to be a good idea. The convention that dimension 0
>referes to the packed part (which has been already assumed to be
>1-dimensional)
>and dimensions > 0 refer to the unpacked part would allow to unify those
>functions and omit the qualifiers "Packed"/"Unpacked" from the names.
>The functions unified that way would be as follows:
>
>int svLeft(svHandle h, int d);
>int svRight(svHandle h, int d);
>int svLow(svHandle h, int d);
>int svHigh(svHandle h, int d);
>int svIncrement(svHandle h, int d);
>int svLength(svHandle h, int d);
>int svDimensions(svHandle h);
>
>Thanks for this idea, Francoise!
>
>
> > >Access via canonical representation
> > >-----------------------------------
> > >
> > >This group of functions is meant for accessing elements which are packed
> > >arrays ('bit' or 'logic').
> > >
> > >The following functions will copy a single vector from a canonical
> > >representation to an element of an open array or other way round.
> > >
> > >Element of an array is identified by indices bound by the ranges of the
> > >actual argument. In other words, original SV values are used for indexing.
>
>
>Francoise:
>#########
> > The other alternative is to use a flat offset to the beginning of the
> array
> > rather than the SV
> > indices. The problem of the offset is that the user must calculate it;
> this
> > may be easy
> > in the case of array of bits and logic but more difficult in the general
> > array case.
> > I don't particular disagree with the multiple functions for 1, 2, 3, and
> > var dimensions,
> > but I wanted to bring the other alternative.
>
>Actually, you have both ways, i.e. 'flat offset' and SV indices.
>Function svGetArrayPtr() gives the address of the beginning of the array.
>Then it's up to you whether you calculate the offset yourself or rather
>go with SV indices and call a function.
>
>Allright, I thought that you could only use svGetArrayPtr for arrays which
>elements are
bit or logic.
You say in your proposal "The following functions provide an actual address
of the whole
array or its individual element. These functions will be used for accessing
elements of the arrays
of types compatible with C."
I missed the next sentence saying that
"these functions will also be useful for the vendors because they provide
access to the actual representation for all types of arrays."
thanks for the clarification.
> > >/* functions for translation between simulator's and canonical
> > > representations */
> > >
> > >/* actual <-- canonical */
> > >void svcPutBitArrElemVec32 (svcHandle d, svcBitVec32* s, int indx1, ...);
> > >
> > >/* canonical <-- actual */
> > >void svcGetBitArrElemVec32 (svcBitVec32* d, svcHandle s, int indx1, ...);
>
>
>
>Francoise:
>#########
> > I don't see the width specified as a parameter! Is it missing?
>
>No. It's been deliberately omitted. svcHandle carries enough information,
>including the width.
>
>
>
>
> > >Access to the actual representation
> > >-----------------------------------
> > >
> > >The following functions provide an actual address of the whole array or
> > >of its individual element. These functions will be used for accessing
> > >elements of the arrays of types compatible with C.
> > >
> > >/* a pointer to the actual representation of the whole array of any
> type */
> > >void *svcGetArrayPtr(svcHandle);
> > >
> > >Note that no specific representation of an array is assumed here, hence
> > >a generic pointer void *.
>
>
>
>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. 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.
If the generic pointer is a pointer to a SV type which i not C compatible
(packed arrays) then the C code needs to know the vendor representation.
Correct?
> > >int svcSizeOfArray(svcHandle); /* total size in bytes */
>Francoise:
>#########
> > How is the size function useful?
>
>See Example 4. In short:
> memcpy(svcGetArrayPtr(h1), svcGetArrayPtr(h2), svSizeOfArray(h1));
This archive was generated by hypermail 2b28 : Fri Jan 10 2003 - 13:53:09 PST