Yes, it's flawed. Fortunately, in Shalom's example, N=0 would at least
yield an error because, according to 11.5.1, "The first expression
shall address a more significant bit than the second expression." On
mine, maybe the LRM is silent.
See also page 5-6
http://www.eda.org/sv-ieee1800/Meetings/2010/February/Presentations/John%20Havlicek%20Presentation.pdf
. By the way, it's not actually correct about the case of 0, which is
simply illegal, because 7.4.2 requires a positive integer.
See also http://www.eda.org/svdb/view.php?id=39#c112 .
-- Brad
On Fri, May 7, 2010 at 10:22 PM, Greg Jaxon <Greg.Jaxon@synopsys.com> wrote:
> Shalom's example illustrates how flawed the Verilog part select notation is
> when used algebraically.
> Examine carefully the result for his and your expressions when N=0 (i.e. the
> input is not to be replaced).
>
> Brad Pierce wrote:
>
> Steven,
>
> A simple change would be to lift the restriction that the left operand
> in a stream_expression must be unpacked, as suggested in bullet 3 of
>
> http://www.eda.org/sv-bc/hm/10176.html
>
> so Shalom's example could be written as
>
> out[127:0] = { << { in with [127:N]}, replace with [N-1:0] }} ;
>
> which is already legal today when 'in' and 'replace' are unpacked.
>
> -- Brad
>
> On Fri, May 7, 2010 at 5:58 PM, Steven Sharp <sharp@cadence.com> wrote:
>
>
> I'm not converging either. I would like to understand the intended uses
> better first. I am leary of using variables in part-selects with a bunch
> of special-case restrictions. I would prefer to see if we can design a
> a construct that inherently avoids the problems that are avoided by those
> restrictions.
>
>
> Steven Sharp | Architect | Cadence
>
> P: 508.459.1436 M: 774.535.4149 www.cadence.com
>
>
>
> --
> 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.Received on Fri May 7 23:00:56 2010
This archive was generated by hypermail 2.1.8 : Fri May 07 2010 - 23:03:37 PDT