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

Shalom,

I'm not clear whether "if the expression is an unpacked array" is actually a restriction against packed arrays, or just an incomplete specification. But if the LRM were clarified/enhanced so that the following were obviously legal, would this syntax be enough to meet your needs in Mantis 2684?

module test(input int i, j, input logic [0:1000] v_in, output [0:15] v_out);
   assign v_out = {<< {v_in with [i:j]}};
endmodule

-- Brad

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com]
Sent: Wednesday, May 05, 2010 12:53 PM
To: Brad Pierce
Cc: sv-bc@eda.org; SV_EC List
Subject: Re: [sv-ec] Are variable-width part selects already part of the SV language? (Mantis 2684)

I think it is -- 1800-2009 11.4.14.1 has an explicit rule
for "if the expression is an unpacked array" which should apply
in this case.

Gord.

Brad Pierce wrote:
> Gord,
>
> Do you agree with my reading of the LRM that the following is legal today?
>
> module test(input int i, j, input logic v_in[0:1000], output [0:15] v_out);
> assign v_out = {<< {v_in with [i:j]}};
> endmodule
>
> -- Brad
>
> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com]
> Sent: Wednesday, May 05, 2010 10:59 AM
> To: Brad Pierce
> Cc: sv-bc@eda.org; SV_EC List
> Subject: Re: [sv-ec] Are variable-width part selects already part of the SV language? (Mantis 2684)
>
>
> I don't have any issue with a variable operation in a restricted
> RHS context like a bit-stream cast. Having that be permitted
> in a cast would be fine. There are no dynamic width *types*
> in this situation -- the *operation* is defined in a manner
> that supports dynamic indices, but there is no type that
> incorporates those indices.
>
> If that is all that people want, I'm fine with that.
>
> I will have serious issues with allowing dynamic indices
> in any context in which an expression type width must be computed
> dynamically (i.e. at very least anything that participates in the
> calculations defined in table 11-21 of 11.6). To allow that
> would require substantial work in the core Verilog type
> calculus and would necessitate the introduction of automatic
> resizing and recalculation of types on a dynamic basis. I'm
> not willing to support that.
>
> Gord
>
>
>
> Brad Pierce wrote:
>> - 1 --- In http://www.eda.org/svdb/view.php?id=2684 , Shalom requests --------------------
>>
>> Non-constant width part selects
>>
>> - 2 --- In http://www.eda.org/svdb/view.php?id=2684#c9352 , Dave writes ------------------
>>
>> I believe this can be handled in the context of a bitstream cast or streaming operator. In the same manner that we allow casing from dynamic to fixed sized unpacked arrays, we could apply the same rules to dynamically sized part selects. As long as the fixed or dynamic size target can accommodate the fixed or dynamically sized source, it should be legal.
>>
>> So the only change required is to allow variable sized part selects as a component of a bitstream cast or streaming operator.
>>
>> - 3 --- In http://www.eda.org/svdb/view.php?id=2684#c9376 , I write ----------------------
>>
>> I like Dave's suggestion, but don't we already have the capability he describes, as long we lift the arbitrary restriction that the left operand in a stream_expression must be unpacked?
>>
>> lhs = { << { v with [i:j] }};
>>
>> A gotcha would be that if there are not enough bits to fill the left-hand side variable, then the 0-padding is on the right.
>>
>> To use { << { v with [i:j] }} directly in an arithmetic expression, one would need to cast it to some type, as mentioned in http://www.eda.org/svdb/view.php?id=1401 .
>>
>> So if this is legal
>>
>> module test(input int i, j, input logic v_in[0:1000], output [0:15] v_out);
>> assign v_out = {<< {v_in with [i:j]}};
>> endmodule
>>
>> why not also the following?
>>
>> module test(input int i, j, input logic [0:1000] v_in, output [0:15] v_out);
>> assign v_out = {<< {v_in with [i:j]}};
>> endmodule
>>
>> --------------------------------------------------------------------------------------------
>>
>> -- Brad
>>
>>
>>
>

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.