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

Shalom,

What should happen when there's a width mismatch between the result of
a concatenation with variable-width operands and its assignment-like
target? Today, without variable-width operands, the language
right-aligns and then either truncates or zero-fill on the left.

It would be a help if the result of a concatenation would continue to
have a fixed width, and we could treat that mismatch as an error when
there are variable-width arguments, as if the result had been
statically cast with the rules of 6.24.3.

Yet another policy, which I don't like, but mention because of its SV
precedent, would be to only error when there are too many bits, but
when there are too few bits then left-align and zero-fill on the
right, as if it had been streamed with the rules of 11.4.14.

-- Brad

On Fri, May 7, 2010 at 8:35 AM, Bresticker, Shalom
<shalom.bresticker@intel.com> wrote:
> I believe this would cover a large percent of the cases.
>
> Shalom
>
>> -----Original Message-----
>> From: bradpiercephd@gmail.com
>> [mailto:bradpiercephd@gmail.com] On Behalf Of Brad Pierce
>> Sent: Friday, May 07, 2010 6:34 PM
>> To: Bresticker, Shalom
>> Cc: Rich, Dave; sv-bc@eda.org; SV_EC List
>> Subject: Re: [sv-bc] RE: [sv-ec] Are variable-width part
>> selects already part of the SV language? (Mantis 2684)
>>
>> 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.
>> >
>> >
>>
> ---------------------------------------------------------------------
> 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.