Is it normal for this combinational code to generate latches?

Question

I am doing some investigation on what kind of code does/does not generate latches on different synthesizers. The code below drives a 7-segment display from a 4-bit input. I would expect it not to generate latches, because all possible cases are covered in the conditional signal assignment.

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity seven_seg_conditional is
    port (
        value: in std_logic_vector(3 downto 0);
        digit: out std_logic_vector(6 downto 0)
    );
end;

architecture behavior of seven_seg_conditional is
    signal value_int: integer range 0 to 15;
begin
    value_int <= to_integer(unsigned(value));

    digit <=
        "0111111" when value_int = 0 else
        "0000110" when value_int = 1 else
        "1011011" when value_int = 2 else
        "1001111" when value_int = 3 else
        "1100110" when value_int = 4 else
        "1101101" when value_int = 5 else
        "1111101" when value_int = 6 else
        "0000111" when value_int = 7 else
        "1111111" when value_int = 8 else
        "1101111" when value_int = 9 else
        "1110111" when value_int = 10 else
        "1111100" when value_int = 11 else
        "0111001" when value_int = 12 else
        "1011110" when value_int = 13 else
        "1111001" when value_int = 14 else
        "1110001" when value_int = 15;
end;

If I run it through Quartus 13.0, a latch is generated on each output. Is this correct behavior for a synthesizer as per the ongoing standards?

Note: if I rewrite the code using a case statement then there are no latches, even though I never added a when others clause. If I add an unconditional else clause at the end there are no latches as well.

Answer 1

If I run it through Quartus 13.0, a latch is generated on each output. Is this correct behavior for a synthesizer as per the ongoing standards?

The applicable standard (IEEE Std 1076.6-1999/2004, 8.9.5.1 Conditional signal assignment) defines what syntactical constructs will be recognized for synthesis, not how they are interpreted. That leaves the syntactical meaning found in the VHDL LRM (IEEE Std 1076-1993/2002, year supported varying by synthesis vendor, generally not all inclusive either, no standard for VHDL 2008).

When you add an "unconditional else":

    "1110001" when value_int = 15 else (others => 'X');
end;  

The thinking goes that conversion functions are essentially ignored and the equivalent condition expression to_integer(unsigned(value)) = 15, etc. doesn't cover all the choices for value. Also 'X' assignments are ignored for synthesis and the else requires something.

A concurrent conditional signal assignment has an equivalent process comprised of if then elsif then ... end if. You could postulate the presence of the trailing else conveys that all choices are covered.

Expressions are evaluated during simulation (e.g. value_int = 15). There either needs to be something in the syntax to signal all choices are covered or the choices have to be all inclusive.

Note that a VHDL simulator get's rid of the uncertainty in your original concurrent signal assignment statement expressions by the package numeric_std TO_INTEGER outputting an assertion warning - "metavalue detected, returning 0". Using value_int has the savings grace of only generating one warning when a value other than a '1' or '0' is detected as an element of the array value.

The range of the integer value_int implies a bit array size. Type conversions have no real meaning for synthesis which is concerned with binary logic.

If you ignore conversion functions and through synthesis 'magic' assume say 15 is representable as a binary value then there isn't anything signaling the choices are all inclusive without the trailing else to not infer latches.

Could a vendor do a better job converting the concurrent signal assignment to logic? Likely, by not deferring to the original array subtype value. Is the behavior you describe correct for ongoing standards? It appears to be. Standards tend to shy away from areas that can conflict between vendors covering instead common ground.

You could also imagine there should be some reasonable limit on the inference of latches, in this case because of combinatorial delays (difference in rise and fall times) in the evaluated expressions. It isn't generally safe to infer a latch enable by gates representing state, there are cases where inferring latch enables should be an error although the inference of latches would work with a one hot state machine or ring counter, which doesn't match the expressions evaluating value.