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

> I would prefer just to allow integral variable-width part selects in the
> context of an explicit cast.

Problem is, we can't judge if that's sufficient until we're provided
with some actual test cases or some more detailed requirements.

Before I vote for this item, I'd like to know what I'd be signing up to.

-- Brad

On Wed, May 5, 2010 at 10:36 PM, Rich, Dave <Dave_Rich@mentor.com> wrote:
> Brad,
>
> Section 11.4.14.4 is clear to most readers that the expression to the
> left of the 'with' clause in a streaming operation is restricted to an
> unpacked array. I don't think we want to relax that restriction unless
> streaming operation is in the context of a cast to a recognized data
> type.
>
> I would prefer just to allow integral variable-width part selects in the
> context of an explicit cast.
>
> bit [31:0] a,b;
> int i.j,k;
>
> a = 32'(b[i:k])+32'(a[k-1:j]); // streaming operators cannot work kere
>
>
> /Dave
>
>> -----Original Message-----
>> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> Brad
>> Pierce
>> Sent: Wednesday, May 05, 2010 5:04 PM
>> To: Bresticker, Shalom
>> 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)
>>
>> 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.
>>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.