Re: [sv-bc] RE: [sv-ec] Are variable-width part selects already part of the SV language? (Mantis 2684)

From: Brad Pierce <brad_pierce@acm.org>
Date: Sat May 08 2010 - 23:48:40 PDT

Steven,

Your version with 'foreach' is as clear as Shalom's original

     foreach (out[i])
        out[i] = (i >= N) ? in[i] : replace[i] ;

So his example doesn't demonstrate a need for variable width part-selects.

Even in Verilog-1995 it's clear enough

    for (i = 0; i < 128; i = i+1)
      out[i] = (i >= N) ? in[i] : replace[i];

Or with SV tools that don't yet support 'foreach'

`FOREACH(out,i)
    out[i] = (i >= N) ? in[i] : replace[i] ;

with

`define FOREACH(A,I) for (int I = $left(A,1); I !=
$right(A,1)-$increment(A,1); I -= $increment(A,1))

-- Brad

On Fri, May 7, 2010 at 11:56 PM, Steven Sharp <sharp@cadence.com> wrote:
> Thinking about Shalom's example from a HW perspective, this is a set
> of 2-to-1 muxes with different select logic for each of the muxes.
> The logic is such that it selects the second input for the lowest N
> muxes, and the first input for the upper ones.
>
> The existing operator for a mux is the conditional operator, but that
> uses the same select bit value to control all of the output bits.  I
> have suggested before that it would be useful to have a bitwise
> conditional operator, where the select is a vector as wide as the
> inputs, and each bit of the select vector controls the selection of
> the corresponding bit of the output.
>
> Making up a syntax that uses ?? instead of ? to represent the bitwise
> version of the operator,
>
>        out = select ?? in1 : in0;
>
> would be equivalent to
>
>        foreach (out[i])
>                out[i] = select[i] ? in1[i] : in0[i];
>
> while
>
>        out = select ? in1 : in0;
>
> is equivalent to
>
>        foreach (out[i])
>                out[i] = select ? in1[i] : in0[i];
>
>
> This could then be used to express Shalom's example, if there is some
> intuitive idiom for creating a vector with N bits 1 (or 0) and the
> rest the opposite.  I don't know if this version is intuitive, but
>
>        out[127:0] = ('1 << N) ?? in : replace;
>
> Even if there were such an operator, I don't know that this would be
> what you would think of given this problem to solve.  Perhaps it depends
> on how much you are thinking of the actual hardware that it represents.
> It does seem more straightforward than trying to code the mux with
> bitwise logic as
>
>        out[127:0] = (('1 << N) & in) | (~('1 << N) & replace);
>
> It could also be less pessimistic than the bitwise logic in situations
> where the selector was unknown, like the existing conditional operator.
>
> I also don't know that this would apply to a significant number of the
> situations where a variable part select is desired.  In this case, the
> positions of the bits didn't change with N, just which was selected.  In
> other cases, the positions might change.  Here, the variable ends of
> the two selects were at the point where they met.  If you were trying to
> code a barrel shifter where the vacated positions came from another
> vector, for example, this wouldn't help.  But I would think that would be
> more naturally represented with a shift anyway:
>
>        out[127:0] = { new_bits, old_bits } >> N;
>
> instead of trying to use variable part selects
>
>        out[127:0] = { new_bits[N-1:0], old_bits[127:N] };
>
>
> The shift version works correctly for N==128, without the reversed index
> problem of the variable part select version.  The same is true of my
> mux version of Shalom's example.
>
> There are things that could be done with the variable part selects that
> could not be done with the vector conditional operator.  There are also
> things that could be done with the vector conditional operator that could
> not be done with the variable part selects.  I don't know how much overlap
> there is for useful cases.  It just happens to apply to Shalom's example.
>
>
> Steven Sharp   |   Architect   |   Cadence
>
> P: 508.459.1436   M: 774.535.4149   www.cadence.com
>
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Sat May 8 23:49:00 2010

This archive was generated by hypermail 2.1.8 : Sat May 08 2010 - 23:51:21 PDT