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: Fri May 07 2010 - 08:34:21 PDT

So it would be sufficient to allow them to be operands in a
concatenation in an assignment-like context?

-- Brad

On Fri, May 7, 2010 at 5:39 AM, Bresticker, Shalom
<shalom.bresticker@intel.com> wrote:
> A recent example was something like this:
>
> We have a 128-bit input vector and a 128-bit replacement vector. N indicates the replacement point. That is, the output vector needs to be composed of bits [127:N] from the input vector and bits [N-1:0] of the replacement vector.
>
> The actual case was more complex, and I am not sure I am summarizing it correctly.
>
> So, the intutitive but illegal way to code this is
>
> out[127:0] = { in[127:N], replace[N-1:0] } ;
>
> To actually get this, you can do something like (I'm not sure this is correct):
>
> {(in >> N), replace << (127-N)} >> N
>
> There are other ways to do this.
> All are ugly, non-intuitive, hard to read, and even harder to write correctly.
> The fact that there are ways to do this means that there are ways to transform the currently illegal form into a legal form.
> Why shouldn't this transformation be automatic instead of forcing the designer to waste his time doing code contortions and usually requiring several passes until he gets it correct?
>
>> Often, what is needed is a combination of variable
>> part-selects that adds up to a constant width, e.g., N bits
>> from vector A, concatenated with 32-N bits from vector B.
>
> Shalom
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri May 7 08:34:47 2010

This archive was generated by hypermail 2.1.8 : Fri May 07 2010 - 08:36:32 PDT