[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 Tue Feb 1 19:33:10 2005