Subject: Re: [sv-cc] DirectC layer: C array indices mapping question
From: Francoise Martinolle (fm@cadence.com)
Date: Mon Feb 03 2003 - 05:58:12 PST
Andrzej,
Yes I understand your mapping for unpacked arrays. I think that for Verilog
arrays
since they are compatible with C arrays, it is not natural or intuitive to
take the smallest
indice and to map it to C index 0.
If I declare an array arr[1:3][2:9], then the indices map nicely to the C
array because
the ranges on the Verilog side are ascending but if they are descending or
even mix, the
user who declares his Verilog array needs to cross map the indices to C.
arr[0:3] [4:2] -> in C the 0,0 indices will correspond to 0,2 of the
original Verilog array
The memory mapping you mentioned which was chosen once upon a time to
implement memories in VXL was for supporting tf_nodeinfo format for
retrieving the
values of memories and variables.
This format retrieves value byte by byte. It is not a very efficient way to
retrieve values
but it is very packed and use less space that aligning the value on words
(like in the
vpi_vecval format.
For instance a memory of 28 1-bit registers declared as
reg mem [27:0] and reg mem[0:27] will be layout exactly the same:
Bits layout
8 -- 1 16 -- 9 24 --17 32//// 27-- 25
byte0 byte1 byte2 pad byte3
Why not instead mapping the Verilog memory and arrays to a C array of
integers where the indices follow the same indices of the Verilog declaration.
For example if the Verilog array is declared as [27:0], the 0 index in C
will contain bit 27
contrarily if the Verilog array is declared as [0:27], C index 0 will
correspond to bit 0.
Packed arrays are layout differently as you said and is very well defined
by the Verilog LRM
a vector of [27:0] will be laid out as 27......0
while a vector of [0:27] will be laid out as 0 ...27
The MSB is the Left bound value of the range and the LSB is the right bound
value of the range.
I am not sure if there is any advantage in either mapping, but I wanted to
point out that
it may not be intuitive to do the mapping you propose.
Francoise
'
At 05:07 PM 1/31/2003 -0500, Andrzej Litwiniuk wrote:
> > I was reading again the DirectC layer proposal you made and trying to
> > understand
> > the mapping you propose for SV unpacked array indices.
>
>Francoise,
>
>We have separate rules for indexing the packed and the unpacked part.
>
>I assume that you were concerned with the rules for 'true' arrays,
>that go under the name "unpacked arrays" in Verilog.
>
>It looks like the rules for unpacked arrays are =different= than for the
>packed
>ones.
>I believe that the rules that I proposed for the unpacked arrays are
>consistent
>with the way the simulators behave; at least in VCS elements of memories with
>smaller indices go first.
>
>SV LRM 3.0 does not explicitly address the ordering of array elements,
>what is justifiable because the actual ordering should be transparent to SV.
>
>Sub-chapter 4.3 of the LRM contains an example that seems to suggest that
>layout shall ber consistent with C:
>
> bit foo2 [1:5] [1:10]; // 1 to 10 varies most rapidly, compatible
> with C
>
>It may be just a concidence for ascending [1:10].
>
>
>
> >
> > You say:
> > "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). "
> >
> > If I apply this to the following example:
> > SV object:
> > v [0:3] [4:3]
> >
> > will be laid out as:
> > a C array: c[4][2]
> > @c[0][0] => v[0][3] | lowest address
> > @c[0][1] => v[0][4] |
> > @c[1][0] => v[1][[3] |
> > @c[1][1] => v[1][4] V increasing C addresses
> > etc...
>
>Right.
>
> > This is different from the way packed vectors are laid out
> > in Verilog simulators.
>
>Well, it depends what do you mean. I dare say that even the packed vectors
>are laid out in the order "least significant" ---> "most significant"
>(cf. PLI legacy avalue/bvalue representation).
>For indices of the unpacked part the arithmetics cannot be used as a criterium
>to define which indices are "least" or "most" significant, so I just
>assume that
>"greater" means "more significant".
>
>And why the rules for array elements (unpacked part) should be the same
>as for sequence of bits in the packed part?
>
>
> > If the packed part is [27:1]
> > then it is laid out as 1 being the LSB
> >
> > If the packed part is [1:27] then 27th is the LSB.
>
>Frankly, I might be wrong with the =packed= part.
>Have to figure it out.
>
>Anyway, LRM 3.0 3.7 "Structures and Unions" contains the following
>sentence:
>"One or more element of the packed array may be selected assuming
>an [n-1:0] numbering"
>
>Andrzej
>
> > Is there a particular reason why you choose the proposed mapping?
> > Why not layout out Verilog like:
> > v[0][4] @c[0][0]
> > v[0][3] @c[0][1]
> > v[1][4] @c[1][0]
> > v[1][3] @c[1][1]
> > etc....
> >
> > This seems to me a more natural way which match the way that people today
> > interpret the packed
> > vector layout of bits.
> >
> > Francoise
> > '
> >
This archive was generated by hypermail 2b28 : Mon Feb 03 2003 - 05:58:43 PST