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
.