VHDL Part 31 : VHDL Part 30's warnings

I am now using ISE version 10.1..I had encountered some warnings in the previous version that were just bugs but already cured in 10.1.

Please see VHDL Part 30 for the code.

The synthesis of MUX code I had posted previously completed successfully. However, it gave me the following warnings on the Transcript subwindow (subwindow at the bottom):
(1) WARNING:Xst:819 - "C:/Xilinx/10.1/tahder/scratch/mux1/mux1.vhd" line 44: One or more signals are missing in the process sensitivity list. To enable synthesis of FPGA/CPLD hardware, XST will assume that all necessary signals are present in the sensitivity list. Please note that the result of the synthesis may differ from the initial design specification. The missing signals are:
(2) WARNING:Xst:737 - Found 2-bit latch for signal . Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.

Some people ignore warnings since the design still runs during simulation. I don't as they warn :) me of some problems that might occur during my synthesis. By 'synthesis' I mean when you implement this on the FPGA board. Some warnings are okay, while some can be removed as in the case with this code. To view full info on the warning, see the Design Summary (if not already open, double click View Design Summary on the Processes Subwindow, the one with the green upper case sigma icon).

Here's how I removed those warnings.

(1) Guided by the Design summary, the inputs mux_in1, mux_in2, mx_in3 and mux_in4 must be included in the process sensitivity list. The process line must be

mux_process : process (mux_sel, mux_in1, mux_in2, mux_in3, mux_in4)

(2) This error is explained by Xilinx as stated above. Remember that latches are not clocked and this may lead to synthesis problems. The two-bit latch that were generated are due to the following lines were mux_out2 are not specified.

when "10" => mux_out1 <= mux_in3;
when "11" => mux_out1 <= mux_in4;

If you still decide to go on with simulation in spite of this warning you will have the following result:
Notice mux_out2 values enclosed by the two markers, between times (200ns and 300ns) and (800ns and 900ns). The selector mux_sel has the same value for both time ranges ("11") but they have different mux_out2. That is also what happened with the value of mux_out2 between times (100ns and 200ns) abd (1100ns and 1200 ns) when mux_sel is "10". The reason for this is that the two values of mux_sel ("10" and "11") do not have any mux_out2 specified for them. And so they will just take the value of whatever specified mux_out2 that precedes them. Notice that the mux_out2 for mux_sel "00" and "01" are specified. Whenever these two ("00" and "01") precedes the other ("10" and "11"), the latter two will just take the mux_out2 of the former two.

The way I get around this is that I assign values for all outputs. However, if I don't want to be specific with some of them and I just don't care what their outputs are, use 'X' which is for assigning all unknown or don't care values. And so the case statement must be

when "00" => mux_out1 <= mux_in1; mux_out2 <= "0011";
when "01" => mux_out1 <= mux_in2; mux_out2 <= "0010";
when "10" => mux_out1 <= mux_in3; mux_out2 <= (others=>'X');
when "11" => mux_out1 <= mux_in4; mux_out2 <= (others=>'X');
when others =>

And my simulation result is


which is what I expected.

Going back to the case statement, I may assign "XXXX" to mux_out2 which is a bit vector. However, if the length of my vector is something like 256, using (others=> ) will be very handy.

Also, you may notice the last two lines

when "11" => mux_out1 <= mux_in4; mux_out2 <= (others=>'X');
when others =>

You may say that since there are only 4 possible inputs, why don't I just put these two in one line.

when others => mux_out1 <= mux_in4; mux_out2 <= (others=>'X');

Well, I did it to be sure during synthesis. I may also do something like

when "11" => mux_out1 <= mux_in4; mux_out2 <= (others=>'X');
when others => mux_out1 <= (others=>'0'); mux_out2 <= (others=>'X');

which is also okay (for me).

;)

References:
(1) Pedroni, V., Circuit Design with VHDL, The MIT Press, 2004.
(2) Xilinx MUX Toolbox