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

Jonathan,

I think we could get a little nearer to the expressibility of VHDL
without endangering the soundness of SV. A step in that direction
would be a simple version of parameterized functions, for example, as
in

    http://bradpierce.wordpress.com/2010/04/28/sv-parameterized-functions/

They're not beautiful, and they're not unconstrained array types, but
still they might make packages more useful.

-- Brad

On Fri, May 7, 2010 at 7:11 AM, Bresticker, Shalom
<shalom.bresticker@intel.com> 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.
>
> --
> 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.