Subject: [sv-cc] Re: nitpick with svGetPartSelectBit() - svGetBits() ?
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Mon Mar 17 2003 - 11:29:42 PST
> I remember originally I think you had this function return
> its value as the function return argument, then later decided
> to pass its output by reference in the interest of symetry
> with svGetSelectLogic().
>
> It would be really nice if this function could be part of
> a C expression rather have to call it to store the result
> in a temp variable then use the temp variable in the C
> expression.
John,
I absolutely agree. What I'm not clear about is what a name should
be used such that it would not confuse the user.
What we need is a function:
svBitVec32 get_bit_part_select(const svBitPackedArrRef s, int i, int w);
and the issue is what should be its name. Another issue: should the procedure
'svGetPartSelectBit' be kept for the sake of mere symetry?
> But in thinking about it, I think this symetric buys us very little
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
Regards,
Andrzej
PS Pls. look also for a comment in the middle of your example, although it's
a bit (pun unintended) unrelated.
> But in thinking about it, I think this symetric buys us very
> little whereas I think the asymetry of a direct function
> return value would be highly worthwhile.
>
> I envision many (most ?) applications that will just be doing
> functional verification that will not care about 4-state
> logic. They will largely use bit vectors. This function
> itself will be heavily used since it facilitates very efficient
> use of the binary compatible canonical form (svc.h).
> That is, by using this function, you avoid the vector copy
> overhead when you only care about specific slices of
> vectors (which will probably be 90% of the time).
>
> It would be really nice if this function could be part of
> a C expression rather have to call it to store the result
> in a temp variable then use the temp variable in the C
> expression.
>
> For example consider this imported C function that
> can be called from SV to pass an ethernet packet header vector,
>
> This version,
>
> // imported C function:
> void ReceivePacketHeader( svBitPackedArrRef etherHeader ){
> svBitPackedArrRef etherHeaderHandle;
>
> // Unpack ether header:
> long long dest_addr
> = svGetPartSelectBit( etherHeader, 32, 32 ) |
> (svGetPartSelectBit( etherHeader, 64, 16 ) << 32);
> long long src_addr
> = svGetPartSelectBit( etherHeader, 80, 32 ) |
> (svGetPartSelectBit( etherHeader, 112, 16 ) << 32);
Putting the main issue aside, shouldn't those pieces of a a long
address be casted to 'long long' before performing shifting and or-ing?
>
> processHeader(
> svGetPartSelectBit( etherHeader, 0, 16 ), // type
> svGetPartSelectBit( etherHeader, 16, 16 ), // length
> dest_addr,
> src_addr,
> svGetPartSelectBit( etherHeader, 128, 32 ) ); // crc
> }
>
> is more concise and readable and *much* less awkward to use than this,
>
> void ReceivePacketHeader( svBitPackedArrRef etherHeader ){
> svBitPackedArrRef etherHeaderHandle;
>
> // Unpack ether header:
> svBitVec32 type;
> svGetPartSelectBit( &type, etherHeader, 0, 16 );
>
> svBitVec32 length;
> svGetPartSelectBit( &length, etherHeader, 16, 16 );
>
> svBitVec32 dest_addr_lower;
> svGetPartSelectBit( &dest_addr_lower, etherHeader, 32, 32 ) |
> svBitVec32 dest_addr_upper;
> svGetPartSelectBit( &dest_addr_upper, etherHeader, 64, 16 );
> long long dest_addr
> = dest_addr_lower | (dest_addr_upper << 32);
>
> svBitVec32 src_addr_lower;
> svGetPartSelectBit( &src_addr_lower, etherHeader, 80, 32 ) |
> svBitVec32 src_addr_upper;
> svGetPartSelectBit( &src_addr_upper, etherHeader, 112, 16 );
> long long src_addr
> = src_addr_lower | (src_addr_upper << 32);
>
> svBitVec32 crc;
> svGetPartSelectBit( &crc, etherHeader, 128, 32 );
>
> processHeader(
> type,
> length,
> dest_addr,
> src_addr,
> crc );
> }
>
> I urge us to consider changing this. Having symetry of functions
> serves very little purpose in this case and forces more awkward
> use of this function which I believe will probably be among the
> most heavily used functions in the C-layer interface.
>
> -- johnS
> __
> ______ | \
> ______________________/ \__ / \
> \ 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 : Mon Mar 17 2003 - 11:31:14 PST