RE: FW: [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.