Vivado bug in handling of partly out-of-bounds parts select

[cliffordwolf]

Consider the following (slightly over-complicated) test case:

    module issue_057(a, y);
      input [2:0] a;
      output [3:0] y;
      localparam [5:15] p = 51681708;
      assign y = p[15 + a -: 5];
    endmodule

This is expected to set **y[3]=1** for **a=1**, but the vivado 2014.2 synthesis output sets **y[3]=0**.

Crosscheck: Verific 35_463_32_140722, Modelsim 10.1e, XSim 2014.2 and Icarus Verilog (git 1572dcd) implement this correctly. Quartus 14.0 suffers from the same bug. (XST 14.7 also suffers from the bug.)

[geoffbarnes]

I would check if out of bounds starting points are legal LRM wise. If not, then there may not be a right answer.

But the localparam size and value could be tweaked so that all values of "a" are in bounds. Maybe like:

localparam [ 5:15+7] p = { xyz, 7'd0 }

[cliffordwolf]

> I would check if out of bounds starting points are legal LRM wise. If not, then there may not be a right answer.

Of course I did check with the LRM _before_ making my post.

See sec. 5.2.1. of IEEE Std. 1364-2005:

Part-selects that are partially out of range shall, when read, return x for the bits that are out of range and shall, when written, only affect the bits that are in range.

(IEEE Std. 1800-2012 has exactly the same wording in sec. 11.5.1.)

The important part here is of course "for the bits that are out of range".

> But the localparam size and value could be tweaked so that all values of "a" are in bounds. Maybe like: localparam [ 5:15+7] p = { xyz, 7'd0 }

I used to add "Note: This is a bug report. I don't need support." to the bottom of my bug reports. I forgot it this time, so I guess I am to blame for getting this kind of replies..

[geoffbarnes]

I getcha..  It's hard to know the context of a post sometimes.

At any rate,  it's funny that all the synthesizers behaved differently than all the simulators.

Pretty nasty bug!   Could cause a lot of lab head scratching..