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

From: John Michael Williams <john@svtii.com>
Date: Fri May 07 2010 - 13:46:59 PDT

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.
Received on Fri May 7 13:44:35 2010

This archive was generated by hypermail 2.1.8 : Fri May 07 2010 - 13:47:21 PDT