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:43:56 2005