06-07-2019 01:00 PM
UG901 (pg. 227, v2018.3 December 19, 2018) states that "Unsized integers in case item expressions can cause unpredictable results.", and it provides the following code example:
reg [2:0] condition1; always @(condition1) begin
4 : data_out = 2; // Generates faulty logic
3'd4 : data_out = 2; // Does work
Could someone please clarify:
1) Is this, in fact, a real issue with Vivado Synthesis and not just some documentation incosistency?
2) If the answer for (1) is yes, then does this limitation really mean that the logic synthesized from this type of coding style is really unpredictable?
3) Since the UG seems to distiguinsh between Verilog and SystemVerilog, does this issue, if true, also apply to files compiled as SystemVerilog?
06-07-2019 01:30 PM
Anecdotally speaking, I have used unsized integers as case item expressions in many SystemVerilog state machines and have never encountered an issue. I have never tried it with Verilog files though.
06-07-2019 01:49 PM
That's an interesting find in the documentation, and a rather perplexing errata.
While I tend to think user guidelines should encourage sizing literals in statements like this, the standard is very clear on the expected behavior. If Vivado is producing a netlist which doesn't match the described, standardized behaviour, then this is a rather serious Vivado bug.
I'm hoping the note in UG901 is more of a strong suggestion for designer coding guidelines, rather than an actual Vivado errata of a real bug.
Note the following item "Integer Handling in Concatenations" - this is EXPLICITLY not allowed by the standard. Simulators will (as Vivado should) error out on such a use case. If Vivado doesn't error out, it's bad, but not as bad as the case problem above. In this instance, the designer is requesting undefined behaviour - you get what you ask for.