Subject: Re: DirectC: C layer - indexing of sized and unsized arrays
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Tue Jan 14 2003 - 16:24:02 PST
Team,
Doug validly noticed that the indexing and normalized ranges had not
been clearly specified and might be confusing, especially that both
SV indexing and C indexing are refered in the doc.
For packed arrays we may refer to the notions of LSB and MSB in SV.
LRM 3.7 seems to suggest that any packed array may be indexed using
[n-1:0] numbering.
LRM does not specify, however, the layout of unpacked arrays.
There are two obvious possible orderings of elements and I assume
a more natural one: elements with lower indices go first.
Therefore for a range [l:r] we have the following mapping from SV indices
to normalized indices:
packed array: LSB --> 0, MSB --> abs(l-r)
unpacked array: min(l,r) --> 0, max(l,r) --> abs(l-r)
The relevant part of the doc have been modified as follows:
::::::::::::::::::::::::::::::::::::::::::::::::::::::
Representation of the data
--------------------------
.....
d) layout of sized unpacked arrays is same as used by C compiler;
this includes arrays embedded in structures and the standalone arrays
(i.e. not embedded in any structure)
.....
A natural order of elements is assumed for each dimension in the layout of
an unpacked array, i.e. elements with lower indices go first.
In other words, for SV range [l:r], the element with SV index min(l,r) will
have C index 0, and the element with SV index max(l,r) will have C index
abs(l-r).
.....
Access to data
--------------
.....
For unsized (open) arrays the original SV ranges are used in indexing.
For sized arrays normalized ranges are assumed.
Normalized ranges mean [n-1:0] indexing for the packed part, and [0:n-1]
indexing for the unpacked part of an array.
Therefore a packed array of range [l:r] will be normalized as [abs(l-r):0],
its most significant bit will have a normalized index abs(l-r), and its least
significant bit will have a normalized index 0.
.....
::::::::::::::::::::::::::::::::::::::::::::::::::::::
Doug, will the above provide enough clarification?
Andrzej
> > /* functions for bit-select and limited width part-select */
> >
> > /* Packed arrays are assumed to be indexed n-1:0,
> > where 0 is the index of least significant bit */
> >
> >
> >
> > Open (Unsized) Arrays and Abstract Access - Overview
> > ====================================================
> >
> > All open arrays, packed (i.e. vectors) and unpacked (i.e.
> > arrays per se)
> > will be passed by handle and accessed mainly via accessory
> > functions (abstract
> > access).
> >
> > Abstract access for open arrays will allow inquires about the
> > dimensions
> > and the original boundaries of SV actual argument and will
> > allow to access
> > the elements of an open array using the same range of indices
> > as in SV.
> >
> > The programmer will always have a choice, whether to specify a formal
> > argument as a sized array or as an open (unsized) array.
> >
> > In the former case all indices will be normalized on the C
> > side (i.e. 0 and up)
> > and the programmer is assumed to know the size of an array.
> > Programmer is also assumed to be capable of figuring out how
> > the ranges of
> > the actual argument will map onto C-style ranges.
> > Hint: programmers may decide to stick to [n:0]name[0:k] style
> > ranges in SV.
>
> DOUG: I would like to see this exposition part briefly discuss
> array range direction topics:
> - When using the term "LSB" in this document, exactly what is
> it referring to? The LSB of the normalized C array?
> Or the LSB of the formal SV argument?
> When referring to the LSB of the actual argument it seems we
> are referring to the rightmost bit of the argument.
> When referring to the LSB of the formal argument it seems we
> are referring to the 0'th bit of the normalized C array.
> I'm thinking about the following kind of situations on the SV side:
>
> extern "C" void userSvFuncDesFormal(input logic[31:0] formalArg);
> extern "C" void userSvFuncAscFormal(input logic[0:31] formalArg);
>
> reg [31:0] descendingReg;
> reg [0:31] ascendingReg;
> reg someScalar;
>
> userSvFuncDesFormal(ascendingReg);
> userSvFuncDesFormal(descendingReg);
> userSvFuncDesFormal({descendingReg[30:0], someScalar});
> userSvFuncAscFormal(ascendingReg);
> userSvFuncAscFormal(descendingReg);
> userSvFuncAscForma({someScalar, ascendingReg[2:31], someScalar);
> - When using the word "ascending" (or "incrementing", as you have done)
> what exactly is it referring to? It must be referring to the
> actual SV argument side.
>
> I hope these thoughts give you some ideas on how to clarify this topic.
> I think clarifications will be necessary for unambiguous reading
> of the spec. For the open array case, it does seem we need to
> index based on the SV actual. What will happen if concatenation
> cases such as above are used?
This archive was generated by hypermail 2b28 : Tue Jan 14 2003 - 16:25:32 PST