VHDL Part 37 : Finite State Machine Sample Design Code

I had already illustrated the states I want my signals to go through. I have learned that to be able to design a state machine, I need one combinational and one sequential processes. So now I need to code it.

----------------------------------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity fsm1 is
port(
clk : in std_logic;
rst : in std_logic;
cond_1 : in std_logic;
cond_2 : in std_logic;
block1_en : out std_logic;
block2_en : out std_logic;
block3_en : out std_logic;
block4_en : out std_logic);
end fsm1;

architecture Behavioral of fsm1 is

-- let me declare my states by enumeration; the present state and next states as signals, the
-- data type of which is my list of states (fsmState)
type fsmState is (idleState, state1, state2, state3, state4);
signal presentState, nextState : fsmState;

begin

-- here's my sequential process
seq_process : process (clk,rst)
begin

if rst = '1' then 

-- idleState is the default state
presentState <= idleState; 

elsif clk'event and clk = '1' then 

presentState <= nextState; 

end if;
end process seq_process;

-- here's my combinational process
comb_process : process (presentState, cond_1, cond_2)
begin

case presentState is

when idleState =>

-- all my blocks are disabled
block1_en <= '0';
block2_en <= '0';
block3_en <= '0';
block4_en <= '0

-- at the next clock (as seen on the sequential process), my next state will be state 1
nextState <= state1; 

when state1 =>

-- enable only block1
block1_en <= '1';
block2_en <= '0';
block3_en <= '0';
block4_en <= '0'; 

-- conditions changed?
if ((cond_1 = '1') and (cond_2 = '0')) then

nextState <= state2;

elsif ((cond_1 = '0') and (cond_2 = '1')) then

nextState <= state3; 

else

nextState <= idleState; 

end if;

when state2 =>

-- enable only block2
block1_en <= '0'; 
block2_en <= '1'; 
block3_en <= '0'; 
block4_en <= '0'; 

-- conditions changed?
if ((cond_1 = '1') and (cond_2 = '0')) then

nextState <= state4; 

else

nextState <= state2; 

end if;

when state3 =>

-- enable only block3
block1_en <= '0'; 
block2_en <= '0'; 
block3_en <= '1'; 
block4_en <= '0'; 

-- conditions changed?
if ((cond_1 = '0') and (cond_2 = '1')) then

nextState <= state4; 

else

nextState <= state3; 

end if;

when state4 =>

-- enable only block4
block1_en <= '0'; 
block2_en <= '0';
block3_en <= '0'; 
block4_en <= '1';

-- conditions changed?
if ((cond_1 = '1') and (cond_2 = '1')) then

nextState <= state1;

else

nextState <= state4; 

end if;
end case;
end process comb_process;
end Behavioral;
----------------------------------------------------------------------------------
I did not have any warnings when I synthesized it. When I tried closing the cases in my case statement with

------------------------------
when others =>

nextState <= presentState;
------------------------------

I have the following warnings

------------------------------
WARNING:Xst:737 - Found 1-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.
WARNING:Xst:737 - Found 1-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.
WARNING:Xst:737 - Found 1-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.
WARNING:Xst:737 - Found 1-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.
WARNING:Xst:1294 - Latch is equivalent to a wire in block .
WARNING:Xst:1294 - Latch is equivalent to a wire in block .
WARNING:Xst:1294 - Latch is equivalent to a wire in block .
WARNING:Xst:1294 - Latch is equivalent to a wire in block .
------------------------------

Ok. I had already completed my case statement with when others. Why is it that I still have WARNING:Xst:737? After I read the warnings carefully, I noticed that ISE has given my outputs latch equivalents which I do not want because it seems to me that my outputs are not clocked. I tried adding the outputs to my when others like so

------------------------------
when others =>

block1_en <= '0'; block2_en <= '0'; block3_en <= '0'; block4_en <= '0'; nextState <= presentState;
------------------------------

The warnings then disappeared.

Yehey ;)

Reference:
(1) Pedroni, V., Circuit Design with VHDL, The MIT Press, 2004.

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