Subject: Re: [sv-cc] Updated LRM - functions for bit type part-selects
From: Stickley, John (john_stickley@mentorg.com)
Date: Wed Mar 19 2003 - 11:07:11 PST
Andrzej,
I think the single most useful function for data extraction
from packed bit vectors is the one you've defined as,
Andrzej Litwiniuk wrote:
> > > svBitVec32 svGetBits(const svBitPackedArrRef s, int i, int w);
This will be the workhorse function for processing slides from
most packed vector function arguments IMHO. If we can provide an
equivalent that will allow us to also conveniently handle packed
arrays between 33 bits and 64 bits in size that would be nice to.
For example to extract the 48 bit destination or source
address from an ethernet header into a long long.
But, at the minimum we need the capability for up to 32 bits
as you suggest. The 48 bit extraction can always represented
as a 16 bit extraction << 32 or'ed with a 32 bit extraction.
As for having dedicated functions to extract whole 32 or
64 bit quantities, I don't think it is worth it. I had misread
your proposal initially and did not notice that these were
fixed bit width extraction functions.
Perhaps for now, in the interest of simplicity, we should
just add the svGetBits() function as you've defined it above
and not bother with the fixed width variants.
-- johnS
Andrzej Litwiniuk wrote:
> > > /* 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
> >
> > It looks good but I would prefer the following for the bit
> > select functions:
> >
> > typedef long long svBitVec64;
> > svBitVec64 svGet64Bits( ... );
>
> John,
>
> I'm afraid that defining the type svBitVec64 may lead to confusion
> and misinterpretation, due to its similarity to svBitVec32.
> Users may think that this is an alternative form of canonical
> representation
> which siimply uses bigger chunks of data. (I remember that you were fond of
> such idea.).
> If you'd rather have a new type, than what about sv64Bits?
>
> typedef long long sv64Bits;
> sv64Bits svGet64Bits( ... );
>
> Function svGet64Bits() is an exception, as generally only narrow (<=32 bit)
> part-selects are supported.
>
>
> > svBitVec32 svGet32Bits(
> > const svBitPackedArrRef s, int i, int w); // Up to 32-bits
> > svBitVec64 svGet64Bits(
> > const swBitPacketArrRef s, int i, int w ); // Up to 64-bits
> >
> > I think it is important to include the 'w' parameter in both so
> > that proper masking can be applied before the result is returned.
> > Plus this is more consistent with what is already in there for
> > svGetPartSelectBit() (and what you have listed for svGetBits()).
> >
> > -- johnS
>
> Parameter 'w' is redundant for svGet32Bits() and svGet64Bits() because
> those functions assume width=32 or width=64, respectively.
> While svGet64Bits() is an exception in narrow-part-selects-only support,
> svGet32Bits(...) is solely a shortcut for svGetBits(..., 32).
>
>
> Regards,
> Andrzej
>
--This email may contain material that is confidential, privileged and/or attorney work product for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. __ ______ | \ ______________________/ \__ / \ \ H Dome ___/ | John Stickley E | a __ ___/ / \____ Principal Engineer l | l | \ / Verification Solutions Group | f | \/ ____ Mentor Graphics Corp. - MED C \ -- / / 17 E. Cedar Place a \ __/ / / Ramsey, NJ 07446 p | / ___/ | / / mailto:John_Stickley@mentor.com \ / Phone: (201)818-2585 \ / ---------
This archive was generated by hypermail 2b28 : Wed Mar 19 2003 - 11:09:18 PST