Subject: Re: [sv-cc] Updated LRM
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Wed Mar 19 2003 - 09:43:57 PST
> Just a quick reminder. Will one of you - be putting in the changes
> to the C-layer regarding the part select functions that we discussed ?
I've already put them, although not sent out yet.
And I'm still thinking whether to eliminate svGetPartSelectBit() along with
"NOTE".
The text looks now as follows:
-------------------------
10.3.2 Part selects
Limited (up to 32-bit) part selects are supported. A part select is a slice of a packed array of types bit or logic. Array slices are not supported for unpacked arrays. Additionally, 64-bit wide part select can be read as a single value of type long long.
Functions for part selects only allow access (read/write) to a narrow subrange of up to 32 bits. A canonical representation shall be used for such narrow vectors. If the specified range of part select in not fully contained within the normalized range of an array, the behaviour is indetermined.
/*
* functions for part select
*
* a narrow (<=32 bits) part select is copied between
* the implementation representation and a single chunk of
* canonical representation
* Normalized ranges and indexing [n-1:0] are used for both arrays:
* the array in the implementation representation and the canonical array.
*
* s=source, d=destination, i=starting bit index, w=width
* like for variable part selects; limitations: w <= 32
*/
NOTE-For the sake of symmetry, a canonical representation (i.e., an array) is used both for bit and logic, although a simpler int can be used for bit-part selects (<= 32-bits):
/* canonical <-- actual */
void svGetPartSelectBit(svBitVec32* d, const svBitPackedArrRef s, int i,
int w);
void svGetPartSelectLogic(svLogicVec32* d, const svLogicPackedArrRef s, int i,
int w);
For the convenience, the following functions return bit type part selects as a single value, for narrow part selects (<= 32-bits) and for 32 and 64 bits.
/* canonical <-- actual */
svBitVec32 svGetBits(const svBitPackedArrRef s, int i, int w);
svBitVec32 svGet32Bits(const svBitPackedArrRef s, int i); // 32-bits
long long svGet64Bits(const svBitPackedArrRef s, int i); // 64-bits
/* actual <-- canonical */
void svPutPartSelectBit(svBitPackedArrRef d, const svBitVec32 s, int i,
int w);
void svPutPartSelectLogic(svLogicPackedArrRef d, const svLogicVec32 s, int i,
int w);
-------------------------
Andrzej
> Here's a re-cap of that discussion:
>
> Andrzej Litwiniuk wrote:
> >> Agree. If nobody objects, I'll remove the current version of
> >> svGetPartSelectBit,
> >> although we may want to keep the name with a different functionality.
> >>
> >> So, a dilemma seems to be as follows:
> >>
> >> 1) keep the same name 'svGetPartSelectBit'
> >> 2) use different name, say svGetBits, in order to avoid confusion:
> >> svBitVec32 svGetBits(const svBitPackedArrRef s, int i, int w);
> >>
> >>
> >> I suppose that cases of extracting 32 bits or 64 bits (in two chunks)
> >> may be
> >> pretty common. What would you think about adding two specialized
> >> functions
> >> just for those cases? Something like this:
> >>
> >> svBitVec32 svGet32Bits(const svBitPackedArrRef s, int i); // fixed
> >> width=32
> >> long long svGet64Bits(const svBitPackedArrRef s, int i); // width
> >> width=64
> >>
> >
> > johnS:
> > This would be great. I like the addition of the 64 bit variant too.
> > I would have no objection to keeping svGetPartSelectBit() as is
> > if we can have these two additional functions on in addition to it.
>
> Thanks,
> -- johnS
This archive was generated by hypermail 2b28 : Wed Mar 19 2003 - 09:45:20 PST