Bug in XST handling of constant first argument in Verilog ?: operator

[cliffordwolf]

In the following test case the output should be constant zero:

module issue_001(a, b, y);
  input [2:0] a;
  input [3:0] b;
  output [0:0] y;
  // the ?: must evaluate to the max width of both cases,
  // even if we can be sure that always the smaller case gets selected
  assign y = &( 1 ? a : b );
endmodule

 Sec. 5.1.13 of the Verilog Standard (IEEE Std 1364-2005) states:

[...] If the lengths of expression2 and expression3 are different, the shorter operand shall be

lengthened to match the longer and zero-filled from the left (the high-order end).

So with the condition beeing constant true, the expression in the parentheses must evaluate to {1'b0, a} and not simply a becasue of the size difference of a and b, thus the &-reduce operator should always see at least this one zero-bit and thus always return 0. But XST does not perform the zero filling and therefore produces an incorrect result.

This is with ISE 14.7 and the following XST settings:

run -ifn issue_001.prj -ofn issue_001 -p artix7 -top issue_001 -iobuf NO

Crosscheck: Vivado 2013.4, Isim 14.7 and Modelsim 10.1d implement this correctly. Quartus 13.1 however seems to have the same bug. (So maybe this is already a bug in Verific?)

Note: This is a bug report. I don't need support.

[debrajr]

As you are using Artix-7, we recommend using Vivado Synthesis for your design. This could be a bug in XST but as we are mostly fixing issues in Vivado as its the next gen tool, only very critical bugs would be targeted to be fixed in XST and only if you are using non 7-series devices which is not in your case.

[cliffordwolf]

debrajr wrote:

As you are using Artix-7, we recommend using Vivado Synthesis for your design. This could be a bug in XST but as we are mostly fixing issues in Vivado as its the next gen tool, only very critical bugs would be targeted to be fixed in XST and only if you are using non 7-series devices which is not in your case.

This is clearly a bug on the frontend side of things. I've also tryied it with -p spartan6 now and get the same result. I'm not using any specific device here, I'm trying to provide a minimal test case.

When exactly is a Verilog frontend bug very critical? Is it ever? Should I stop reporting XST bugs? Generating those minimal test cases is not always trivial and I won't bother if Xilinx is not interested in fixing the bugs in XST anyways.

[markcurry]

This is an explicit simulation / synthesis mismatch.  That's a critical bug in my opinion. 

Thanks Clifford for contructing the very clear testcase.  Xilinx should fix this in ISE IMHO. You've done a lot of the work for them.

I'll keep any eye on any of our code to see if there's any chance of us triggering this bug.  It's quite apparent in Clifford's testcase, but in a larger design where constants are being propogated all over the place, something like this could slip in.

Regards,

Mark