--  Finite State-machines
--
--  There are several methods to code state-machines however following certain 
-- coding styles ensures the synthesis tool FSM (Finite State-Machine) 
-- extration algorithms properly identify and optimize the state-machine as 
-- well as possibly improving the simulation, timing and debug of the circuit. 
-- The following examples are broken down into Mealy implementations.  
-- The basic trade-offs for each 
-- implementation is explained below.  The general recommendation for the 
-- choice of state-machine depends on the target architecture and specifics of 
-- the state-machine size and behavior however typically, Moore style 
-- state-machines implement better for FPGAs and Mealy implement best for 
-- CPLDs.
--
--  Mealy vs. Moore Styles
--
--  There are two well known implementation styles for state-machines, Mealy 
-- and Moore.  The main difference between Mealy and Moore styles is the Mealy 
-- state-machine determines the output values based on both the current state 
-- state as well as the inputs to the state-machine where Moore determines its 
-- outputs solely on the state.  In general, Moore type of state-machines 
-- implement best in FPGAs due to the fact that most often one-hot 
-- state-machines are the choosen encoding method and there is little or no 
-- decode and thus logic necessary for output values.  If a binary encoding is 
-- used, it is possible that a more compact and sometimes faster state-machine 
-- can be built using the Mealy method however this is not always true and not 
-- easy to determine without knowing more specifics of the state-machine.
--
--  One-hot vs. Binary Encoding
--
--  There are several encoding methods for state-machine design however the two
-- most popular for FPGA or CPLD design are binary and one-hot.  For most FPGA 
-- architectures, one-hot is the better encoding method due the the abundance 
-- for FF resources and the lesser fan-in requirements for the next 
-- state-equation (maps better into LUTs).  When targeting CPLDs, binary can 
-- many times work better due to the logic structure of the CPLD and fewer 
-- register resources.  In any case, most modern synthesis tools contain FSM 
-- extraction algorithms that can identify state-machine code and choose the 
-- best encoding method for the size, type and target architecture.  Eventhough
-- this facility exists, many times it can be most advantagous to manually code
-- and control the best encoding scheme f0r the design to allwo better control 
-- and possibly ease debug of the implemented design.  It is suggested to 
-- consult the synthesis tool documentation for details about the state-machine
-- extraction capabilities of the synthesis tool you are using.
--  
--  Safe vs. Fast
--
--  When coding a state-machine, there are two generally conflicting goals that
-- must be understood, safe vs. fast.  A safe state-machine implementation 
-- refers to the case where if a state-machine should get an unknown input or 
-- into an unknown state that it can recover into a known state the next clock 
-- cycle and resume from recovery state.  On the other hand, if this 
-- requirement is discarded (no recovery state) many times the state-machine 
-- can be implemeted with less logic and more speed than if state-machine 
-- recovery is necessary.  How to design a safe state-machine generally 
-- involves coding in a default state into the state-machine next-state case 
-- clause and/or specifying to the synthesis tool to implement the 
-- state-machine encoding in a "safe" mode.  Again it is suggested to consult 
-- the synthesis tool documentation for details about implementing a safe 
-- state-machine.

--Libraries
library IEEE;

--Uses of Libraries
use IEEE.STD_LOGIC_1164.ALL;

--Entity declaration
entity syncfsm is
Port ( 
<clock> : in STD_LOGIC;
<reset> : in  STD_LOGIC;
<output> : out  STD_LOGIC;
--Other inputs/outputs
);
end syncfsm;

architecture Behavorial of syncfsm is

--This is a sample state-machine using enumerated types.
--This will allow the synthesis tool to select the appropriate
-- encoding style and will make the code more readable.

--Insert the following in the architecture before the begin keyword
--Use descriptive names for the states, like st1_reset, st2_search
type state_type is (st1_<name_state>, st2_<name_state>, ...); 
signal state, next_state : state_type; 

--Declare internal signals for all outputs of the state-machine
signal <output>_i : std_logic;  -- example output signal

--Component declaration

begin

--Component mapping

--Other outputs assignments or combinational logic

--Process to synchronize all output signal data and state.
SYNC_DATA: process (<clock>)
begin
if (<clock>'event and <clock> = '1') then
		if (<reset> = '1') then
			state <= st1_<name_state>;
			<output> <= '0';
			--Assign other outputs to internal signals
		else
			state <= next_state;
			<output> <= <output>_i;
			--Assign other outputs to internal signals
		end if;        
	end if;
end process;

--MOORE State-Machine - Outputs based on state only
OUTPUT_DECODE: process (state)
begin
	--Insert statements to decode internal output signals
	--Below is simple example
	case (state) is
		when st1_<name> =>
			<output>_i <= '0';
		when st2_<name> =>
			<output>_i <= '1';
		when others =>
			<output>_i <= '0';
	end case;  
end process;

NEXT_STATE_DECODE: process (state, <input1>, <input2>, ...)
begin
	--Declare default state for next_state to avoid latches
	next_state <= state;  --Default is to stay in current state
	--Insert statements to decode next_state
	--Below is a simple example
	case (state) is
		when st1_<name> =>
			if <input_1> = '1' then
				next_state <= st2_<name>;
			else
				next_state <= st1_<name>;
			end if;
		when st2_<name> =>
			if <input_2> = '1' then
				next_state <= st1_<name>;
			else
				next_state <= st2_<name>;
			end if;
		when others =>
			next_state <= st1_<name>;
	end case;      
end process;

OTHER_PROCESS: process (...)
begin
	case (state) is
		when st1_<name> =>

		when st2_<name> =>

		when others =>

	end case;      
end process;

end Behavorial;