cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Observer
Observer
408 Views
Registered: ‎04-23-2018

Integer Handling in Verilog Case Statements

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

  case(condition1)

    4 : data_out = 2; // Generates faulty logic

    3'd4 : data_out = 2; // Does work

  endcase


end

 

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?

0 Kudos
2 Replies
Highlighted
Contributor
Contributor
395 Views
Registered: ‎10-25-2018

Re: Integer Handling in Verilog Case Statements

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.

0 Kudos
Highlighted
Scholar
Scholar
385 Views
Registered: ‎09-16-2009

Re: Integer Handling in Verilog Case Statements

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.

Regards,

Mark

0 Kudos