[sv-cc] Part Select Utilities: Zeroing and Width parameter

But Jim, there's no reason to think the source value
has "the other bits already zeroed out." (Despite
your slogan about working with 'partial information').

I assume you're not arguing to dispense with the width
parameter but, rather, to have the convention be that
the utility leaves bits higher than w unscathed. True?

Ralph

> -----Original Message-----
> From: Jim Vellenga [mailto:vellenga@cadence.com]
> Sent: Wednesday, February 02, 2005 8:44 AM
> To: Jim Vellenga; Duncan, Ralph; SV-CC
> Subject: RE: [sv-cc] Part Select Utilities: Semantic Clarification
>
> Ralph pointed out to me that my statement
>
> "If we always wanted to zero out the rest of the bits, the
> only reason for "w" would be a value that does not contain
> 0's in the other bits."
>
> is not clear. I agree. Let me try to explain a bit more.
>
> As I see it, we wouldn't need "w" if
>
> a) We wanted to 0 out the other bits, and
>
> b) The source value also had the other bits already zeroed out.
>
> In that case, one would just copy all of the source to all of
> the destination. And the routine would zero out the other
> bits automatically.
>
> In particular, with Ralph's example, since src has the value
> 2 (two's complement), if we do zero out, the result does not
> depend on the value of w unless w < 2.
>
> Hence, I argue that unless the bits greater than or equal to
> w matter, there's no point in using the parameter w at all.
>
> Is that clearer?
>
> Regards,
> Jim
>
> ---------------------------------------------------------
> James H. Vellenga 978-262-6381
> Engineering Director (FAX) 978-262-6636
> Cadence Design Systems, Inc. vellenga@cadence.com
> 270 Billerica Rd
> Chelmsford, MA 01824-4179
> "We all work with partial information."
> ----------------------------------------------------------
>
>
>
> ] -----Original Message-----
> ] From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On
> ] Behalf Of Jim Vellenga
> ] Sent: Wednesday, February 02, 2005 11:15 AM
> ] To: Duncan, Ralph; SV-CC
> ] Subject: RE: [sv-cc] Part Select Utilities: Semantic Clarification
> ]
> ] Ralph,
> ]
> ] My own inclination is to leave the remaining destination
> ] bits untouched -- but explicitly so. Since we have gone
> ] to the trouble of letting the user bound the transfer
> ] by using the "w" parameter, we should let him or her
> ] make use of it.
> ]
> ] If we always wanted to zero out the rest of the bits,
> ] the only reason for "w" would be a value that does
> ] not contain 0's in the other bits. The example you
> ] have given does not meet that criterion. If, on
> ] the other hand, you had set src to -2 and copied
> ] only two bits, then maybe -- but then you're overloading
> ] the function to do two things at once -- copy bits
> ] and mask them. Principles of modularization suggest
> ] that we limit the operation to only one of those.
> ] Let the users take care of the masking for themselves.
> ]
> ] But I do agree that it would help to state explicitly
> ] that the remaining dest bits remain untouched.
> ]
> ] Regards,
> ] Jim Vellenga
> ]
> ] ---------------------------------------------------------
> ] James H. Vellenga 978-262-6381
> ] Engineering Director (FAX) 978-262-6636
> ] Cadence Design Systems, Inc. vellenga@cadence.com
> ] 270 Billerica Rd
> ] Chelmsford, MA 01824-4179
> ] "We all work with partial information."
> ] ----------------------------------------------------------
> ]
> ]
> ]
> ] ] -----Original Message-----
> ] ] From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On
> ] ] Behalf Of Duncan, Ralph
> ] ] Sent: Tuesday, February 01, 2005 10:33 PM
> ] ] To: SV-CC
> ] ] Subject: [sv-cc] Part Select Utilities: Semantic Clarification
> ] ]
> ] ]
> ] ] The behavior of part select utilities needs clarification in
> ] ] two areas:
> ] ]
> ] ] . As the part select utilities' parameters have changed, the
> ] ] ranges involved for
> ] ] source and destination have become more obscure. Our
> ] ] earlier text to
> ] ] clarify this has become obsolete and been removed.
> ] ]
> ] ] . Since the LRM does not specify how utilities that get part
> ] ] selects are to treat
> ] ] destination high bits outside the part's range. We could
> ] ] either zero these bits or refrain
> ] ] from altering them. In any case, we need the LRM to state
> ] ] the desired behavior
> ] ] to prevent contrary implementations and subsequent loss of
> ] ] binary compatibility.
> ] ]
> ] ]
> ] ] Problem 1: Part Select Ranges
> ] ]
> ] ] Originally, part select put/get utility calls involved one
> ] ] item in canonical form (that
> ] ] represented 32 bits worth of bit or logic) and one simulator
> ] ] format item that potentially
> ] ] represented some arbitrary number of bits. This situation
> ] ] provided contextual
> ] ] information about the ranges involved in the operation.
> ] ] Still, we provided the following
> ] ] remarks in E.10.3.2 and in the include files' comments:
> ] ]
> ] ] "In part select operations, the data is copied to or
> ] ] from the canonical representation
> ] ] part ('chunk') designated by range [w-1:0] and the
> ] ] implementation representation
> ] ] part designated by range [w+i-1:i]."
> ] ]
> ] ] Since both items are now parameters and both are in canonical
> ] ] format, less information about
> ] ] the ranges is self-evident. Short remarks similar to those
> ] ] above could help by clearly stating
> ] ] which range applies to the source and which to the
> ] ] destination in the two kinds of operation.
> ] ]
> ] ]
> ] ] Problem 2: Uncertain Get Part Select Behavior
> ] ]
> ] ] Currently, the LRM does not fully define the behavior of get
> ] ] part-select utilities. Starting at the user
> ] ] specified bit, i, in the src vector and given a width, w, the
> ] ] utilities copy bits (i+w-1) down to bit i into
> ] ] destination bits (w-1) down to 0. However, we do not
> ] ] specifiy what happens to destination bits [32:w]
> ] ] when w < 32.
> ] ]
> ] ] The LRM doesn't say whether they are zeroed or not. (E.7.7
> ] ] address a similar but distinct issue).
> ] ]
> ] ] If we don't explicitly state the intended utility behavior in
> ] ] the LRM, we are likely to get different
> ] ] behavior from different vendors -- leading to binary
> ] ] incompatibility and baffled users. Thus, the LRM
> ] ] should clearly state what a call to the utilities should produce.
> ] ]
> ] ]
> ] ] 3. A Proposed Solution
> ] ]
> ] ] A formal proposal is attached, which addresses these two
> ] ] issues by adding a single paragraph
> ] ] to the new section E.10.3 Working with canonical representation:
> ] ]
> ] ] "DPI utilities behave in the following way, given part select
> ] ] parameters of width, w and starting index, i.
> ] ] A utility puts part select source bits [w-1:0] into
> ] ] destination bits [(i+w-1):i] without changing the values of
> ] ] destination bits that surround the part select. A utility
> ] ] gets part select source bits [(i+w-1):0] and copies
> ] ] them into destination bits [w-1:0]. If w < 32, destination
> ] ] bits [31:w] are set to zero."
> ] ]
> ] ] Without a clear statement from the LRM on whether get part
> ] ] select utilitites zero-out high bits or not,
> ] ] we will get both kinds of implementation and get user designs
> ] ] that are not binary compatible. If the group
> ] ] prefers the refrain-from-zero approach, I will gladly alter
> ] ] the proposal to use that, instead.
> ] ]
> ] ] Let us choose an approach and have the LRM explicitly state
> ] ] what behavior users can expect.
> ] ]
> ] ] <below are two examples of problems caused by zeroing and not
> ] ] zeroing respectively>
> ] ]
> ] ] EXAMPLE A. CASE AGAINST ZEROING: Avoid Counter-intuitive Results
> ] ]
> ] ] Automatic zeroing may lead to counter-intuitive results,
> ] ] because the call to a get-part-select utility
> ] ] is effectively delivering 32 bits to the destination
> ] ] parameter each time.
> ] ]
> ] ] // Reasonable Example that doesn't work with zeroing
> ] ]
> ] ] The user creates a 32-bit pattern in the destination, then
> ] ] asks that a small number
> ] ] of bits be copied to the destination, with zeroing this
> ] ] actually clobbers the destination high bits.
> ] ]
> ] ] SV code:
> ] ]
> ] ] module goodtop;
> ] ]
> ] ] // import just calls std. utility svGetPartselBit
> ] ] import "DPI-C" function void test_getPartselect(
> ] ] output bit [31:0] dest,
> ] ] input bit [95:0] src,
> ] ] input int index,
> ] ] input int width);
> ] ]
> ] ] bit [95:0] src;
> ] ] bit [31:0] dest;
> ] ] bit b0 = 0, b1 = 1;
> ] ]
> ] ] initial
> ] ] begin
> ] ] src[34:30] = {5{b0}};
> ] ] dest = {32{b1}}; // dest initialized to all 1s
> ] ] test_getPartselect(dest, src, 30, 5); // ask for 5 zeroes
> ] ] in low dest bits
> ] ] $display("SV result:%b",dest," should be 27 ones, 5
> ] zeroes",dest);
> ] ] // the actual result is all zeroes
> ] ] end
> ] ] endmodule //
> ] ]
> ] ] C code:
> ] ]
> ] ] void test_getPartselect(
> ] ] svBitVecVal* dest,
> ] ] svBitVecVal* src,
> ] ] int index,
> ] ] int width)
> ] ] {
> ] ] svGetPartselBit( dest, src, index, width);
> ] ] }
> ] ]
> ] ]
> ] ] EXAMPLE B. CASE FOR ZEROING: Avoid Insidious Errors
> ] ]
> ] ] When the svGetPartsel utilities don't zero out destination
> ] ] bits outside the part-select size,
> ] ] successive calls to the utility can leave high bit settings
> ] ] the user doesn't expect, (unless the user
> ] ] knows to zero out these bits). This is true whether the
> ] ] implementation delivers a vector address
> ] ] that is in the original SV space or some other location. In
> ] ] the case below, the user may assume
> ] ] that previous values of 'bVector' can't possibly persist,
> ] ] because its direction mode, 'output,' seems
> ] ] to preclude ever sending previous values back into C.
> ] ]
> ] ] SV CODE: uses flag to ask for 2 different bit patterns
> ] ]
> ] ] module goodtop;
> ] ]
> ] ] import "DPI-C" function void get_vector(
> ] ] output bit [31:0] bVector,
> ] ] input int cntrlFlag);
> ] ]
> ] ] bit [31:0] bv;
> ] ]
> ] ] initial
> ] ] begin
> ] ] get_vector(bv, 0); // use flag to ask for all 1s
> ] ] get_vector(bv, 1); // use flag to ask for '2'
> ] ] // actual value of 'bv' at this point will be 11111...110
> ] ] end
> ] ] endmodule //
> ] ]
> ] ] C CODE:
> ] ] <snip>
> ] ] void get_vector(svBitVecVal* dest, int flag){
> ] ] svBitVecVal src;
> ] ]
> ] ] if (!flag) {
> ] ] src = 0xffffffff; /* expect to deliver all 1s */
> ] ] svGetPartselBit( dest, &src, 0, 32);
> ] ] }
> ] ] else {
> ] ] src = 0x2; /* expect to deliver 2 */
> ] ] svGetPartselBit( dest, &src, 0, 2);
> ] ] }
> ] ] }
> ] ]
> ] ] DISCUSSION: The first call leaves the word at the 'dest'
> ] ] address = 0x111...1. Since the next call to
> ] ] svGetPartselBit gets a part select less than 32 bits wide,
> ] ] the destination high bits remain unperturbed
> ] ] and are propagated to SV as part of the second call's results.
> ] ]
> ] ] Since 'dest' is output mode, its existing value should not be
> ] ] employed by the user. In this case,
> ] ] however, the user makes no explicit effort to use this value
> ] ] and is unlikely to realize that, effectively,
> ] ] the leftover value is being used.
> ] ]
> ] ]
> ]
> ]
> ]
>
Received on Wed Feb 2 08:55:03 2005