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

Dave,

> I believe that most people on the committee seem to converging on enhancement where

I'm not converging on making the enhancement, I'm only converging on what the enhancement would be if we made it. That is, I've just been trying to figure out the details of the request, so that I can determine the cost component of the ROI.

-- Brad

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Rich, Dave
Sent: Friday, May 07, 2010 2:16 PM
To: J. M. Williams
Cc: 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)

John,

I believe that most people on the committee seem to converging on
enhancement where a variable width part select would be OK in the
context of a cast, a concatenation, or streaming operator where the
resulting type is determined by the context of an assignment to the
destination type. So if you had

bit [127:0] A,B;
int N;

A = {A[127:N],B[N-1:0]}; // would be legal
A = {A[127:N],B[N-1:0]} + 1; // should never be legal
A = type(A)'(A[127:N]) + 128'(B[N-1:0]); // would be legal

We'll need a few more rules about out-of-range and reverse index
ordering, but I'd wait until we get an actual proposal before spending
more time on this.

Dave

> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
John
> Michael Williams
> Sent: Friday, May 07, 2010 1:47 PM
> Cc: sv-bc@eda.org; SV_EC List
> Subject: Re: FW: [sv-bc] RE: [sv-ec] Are variable-width part selects
> already part of the SV language? (Mantis 2684)
>
> Hi.
>
> Maybe stating the obvious, assuming bitwise intent,
> an expression such as A[127:N] & B[N-1:0]
> would depend on whether it was in an expression or
> part of the right-hand side of a statement.
>
> If in a statement, it would be evaluated first by
> adjusting the widths of the two operands to equal
> the width of the destination.
>
> Keep in mind that the "expressive power" of VHDL is far
> less than that of any modern general programming
> language such as C, and that SystemVerilog already has
> imported much of the "expressive power" of C++.
>
> Maybe the variable width part-selects might be limited to
> expressions within a class?
>
> Also, consistent with Jonathan's last point, maybe,
> sometimes, "expressive power" is another name for
> "diversity of gibberish" and "risk of failure"?
>
> On 05/07/2010 07:11 AM, Bresticker, Shalom wrote:
> > ________________________________
> > From: Jonathan Bromley [mailto:jonathan.bromley@verilab.com]
> > Sent: Friday, May 07, 2010 5:10 PM
> > To: Bresticker, Shalom
> > Subject: Re: [sv-bc] RE: [sv-ec] Are variable-width part selects
> already part of the SV language? (Mantis 2684)
> >
> > Shalom,
> >
> > with apologies for sending this directly to you:
> > I still can't get mail to the reflector, thanks to some IT voodoo
> somewhere.
> >
> > [Paul Graham]
> >> For what it's worth, variable width and variable offset part
> >> selects have always been part of vhdl. Vhdl has no special
> >> syntax to distinguish variable part selects from constant
> >> part selects, so a tool has to do some analysis to see which
> >> forms it can support and which it can't.
> >
> > But this reflects a completely different way of thinking about
vector
> widths in VHDL
> > than in Verilog. A VHDL slice's type is a subtype of some base
type,
> and
> > its assignment-compatibility with some target is checked at runtime
-
> types
> > are checked at compile time, subtypes are checked at runtime.
> Synthesis
> > is entitled to complain if the subtype of an expression is not
> statically
> > determinable, but simulation must live with it and throw an error at
> > runtime if you attempt to use something in a way that's not
appropriate
> > to its subtype (such as copying it to a target of the same type but
> > different subtype). And yes, of course, that does impose a runtime
> > cost in some situations.
> >
> > But it brings with it the wonderful power of unconstrained
subprogram
> > arguments. So, for example, the concatenation
> >
> > A(127 downto N)& B(N-1 downto 0)
> >
> > is in fact a call to function "&", whose local variables, and return
> > "variable", are elaborated dynamically when the function is called.
> > The returned result will indeed have 128 bits (even if N is +128
> > or -1, making one of the operands be a null or zero-width slice).
> > It's a moot point whether synthesis can do enough algebra to
> > be able to work out that invariant for itself.
> >
> > I don't really see how anything like this could be grafted on to
> > Verilog at this stage without spectacular and wide-ranging fallout.
> > I sense that there is some frustration among the design community
> > that Verilog lacks the expressive power of VHDL when it comes
> > to writing general-purpose subprograms, but it would be a bad
> > mistake to try to adopt some half-baked form of dynamic subtype
> > as if this were a "feature" that could be added independently of
> > the rest of the language.
> >
> > Of course, queues and dynamic arrays make all this largely
> > irrelevant outside the world of RTL.
> >
> > Thanks
> >
> > Jonathan Bromley
> >
> >
---------------------------------------------------------------------
> > 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.
> >
>
> --
> John Michael Williams
> Senior Adjunct Faculty
> Silicon Valley Technical Institute
>
> --
> 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.