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

________________________________
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.

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