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

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.

I'll send a recent example later.

Shalom

> -----Original Message-----
> From: bradpiercephd@gmail.com
> [mailto:bradpiercephd@gmail.com] On Behalf Of Brad Pierce
> Sent: Thursday, May 06, 2010 10:12 AM
> To: Rich, Dave
> Cc: Brad Pierce; Bresticker, Shalom; 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)
>
> > 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.
> >
> >
> >
>
---------------------------------------------------------------------
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.