Re: [sv-cc] DirectC layer: C array indices mapping question


Subject: Re: [sv-cc] DirectC layer: C array indices mapping question
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Fri Jan 31 2003 - 14:07:52 PST


> 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 : Fri Jan 31 2003 - 14:09:02 PST