There is no "don't care" for integer; if you are modelling digital logic with X, Z, don't care etc, then numeric_std.signed/unsigned is the right way to go.
But look at the numeric_std package more carefully; most operators including =
are overloaded with forms that allow mixing [un]signed and integer freely, so that if my_unsigned_var = 3
just works...
What you can do is create an idle state, and when you detect a button press you switch straight to the idle. Then you can have a counter in idle which waits for a while before you start scanning buttons again.
For example:
-- include numeric std
signal idle_counter : unsigned(31 downto 0);
...
when state3 =>
case bcd_val is
when "01" =>
Send <= '1';
scannel_val <= "0101";
fsm_state <= idle; -- switch to idle
when "10" =>
Send <= '1';
scannel_val <= "0110";
fsm_state <= idle; -- switch to idle
when others =>
scannel_val <= "0000";
Send <= '0';
fsm_state <= state1; -- carry on scanning
end case;
idle_counter <= (others => '0');
...
when idle =>
if (idle_counter < some_timeout) then -- some_timeout is how long you want to wait (in clock cycles)
idle_counter <= idle_counter + "1"; -- increment counter
fsm_state <= idle; -- stay here
else
idle_counter <= (others => '0'); -- reset counter
fsm_state <= state1; -- go back into checking
end
--scannel_val is valid here, so you can do something with it if you'd like.
...
when others => scannel_val <= "0000";
There is one process in this code you've posted.
It starts with
scan_fsm : process (reset, clk) <= Sensitivity list
begin -- process key_scanner
and ends with
end process scan_fsm;
The clock and reset are part of the sensitivity list. That means that this code is only going to be triggered when either clock changes or reset changes.
De-bouncing can be done in a separate process.
Basically, you want to make sure that the button was pressed for a number of microseconds before it triggers. What we want to do is save the value of the input for a number of clock cycles. Then only register a 1 when the history has been constantly 1 for for the past 32 clock cycles.
Example:
-- these are our row inputs (to become bdc_val)
signal row1 : in std_logic;
signal row2 : in std_logic;
...
-- this is our history vector
signal row1_z : std_logic_vector(31 downto 0);
signal row2_z : std_logic_vector(31 downto 0);
-- debounced signal
signal bcd_val : std_logic_vector(1 downto 0);
-- a whole vector of ones for convenience
signal ones : std_logic_vector(31 downto 0);
...
ones <= (others => '1');
-- generate our histories
gen_z : process (reset, clk)
begin
if (reset = '1') then
row1_z <= (others => '0');
row2_z <= (others => '0');
bcd_val <= (others => '0');
elsif (rising_edge(clk)) then
row1_z(31 downto 1) <= row1_z(30 downto 0); -- shift everything up 1
row1_z(0) <= row1; -- save the most recent input
row2_z(31 downto 1) <= row2_z(30 downto 0); -- shift everything up 1
row2_z(0) <= row2; -- save the most recent input
-- we only want bcd_val to be 1 when the entire row history for the past 32 cc is 1
if (row1_z = ones) then
bcd_val(0) <= '1';
else
bcd_val(0) <= '0';
end
if (row2_z = ones) then
bcd_val(1) <= '1';
else
bcd_val(1) <= '0';
end
end
end
Best Answer
Look into doxygen + graphviz to document your design. The graphviz / dot package lets you describe directed graphs (nodes + edges) which can be useful for drawing state diagrams. (If you're using verilog instead of VHDL, check out doxverilog.) I've recently started using this tool to document state machines in code I've inherited from another engineer.
However, I don't know of any tool to automatically reverse-engineer (recognize and extract) "state machine code" as distinct from just plain RTL code and localparams not meant to be a state machine. Even if you could reliably extract the possible states and their transitions, understanding what each state is intended to do still requires a human. So it's still up to you to understand the HDL code you're trying to document.