[sv-cc] nitpick with svGetPartSelectBit()

Subject: [sv-cc] nitpick with svGetPartSelectBit()
From: Stickley, John (john_stickley@mentorg.com)
Date: Fri Mar 14 2003 - 16:10:06 PST

Andrzej,

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().

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);

         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 : Fri Mar 14 2003 - 16:12:13 PST