Electronic – Time parameters of pressing a tact button by people

Here is a digital domain solution. There is not a name for a component that fits the function you describe, but you can use a synchronizer together with a finite state machine.

^{simulate this circuit – Schematic created using CircuitLab}

Synchronizer

First, your finger is not synchronized to the clock, so the button is assumed to be an asynchronous signal. If the input changes close to the clock it could violate setup or hold time requirements of the DFF0. This can cause the output of DFF0 to be unpredictable (metastable), even a non-logical level. A DFF going metastable is kind of like a coin landing on its side when you flip it. It should be 0 or 1 but actually, in rare cases, it isn't.

The problem is not that the DFF will latch a new value 1 cycle early or late, the problem is that the output may glitch back and forth before stabilizing on a particular value. This could be bad downstream of the design. In this case, our FSM may output a glitch or a pulse that is two clock cycles, for example. The probability that metastability will happen is usually quite low and depends on your DFF, operating clock speed, supply voltage, random noise, and the precise time you push the button.

This problem is called a clock domain crossing (CDC) and requires a synchronization technique. A popular approach is just two DFFs like above. This adds a latency of two clock cycles to the input signal, but this delay is trivial in your application. The synchronizer doesn't eliminate the problem entirely, but makes it an extremely low possibility. Errors due to not addressing a CDC are notoriously difficult to debug. You may pass 1000 tests and fail test 1001. This can lead to painstaking tracing and debugging to try to find the source of the very rare error.

If what you are building has a low tolerance for errors, you should use a synchronizer. You can use the one like above, or use one with three DFFs for even lower probability of failure. Otherwise, if you can tolerate an occasional error, you can get away with just two DFFs and an AND gate for your entire design.

The level of robustness in design should match your application. If you are building a mission critical circuit like a rocket guidance system, you probably should use a 3 DFF synchronizer. If you are building a consumer product with high reliability, go with the 2 DFF synchronizer. If its for a McDonald's happy meal toy, just use a single DFF. A good electrical engineer should be aware of the MTBF requirements for the design, and calculate the probability of failure allowable for the button circuit, the actual failure rate of the synchronizer choices, and choose accordingly.

Finite State Machine

What you want for your pulse generator is actually a finite state machine. Whether you are a complete beginner or a seasoned pro, starting with a state diagram is always recommended.

We start in state A. When the input switches to 1, we want the output, \$ y[n] \$, to be 1. One clock cycle later, \$ y[n] \$ should return to 0, so we need to change the state to B to remember not to output 1. Then we wait for \$ a[n] \$ to be 0 before the state returns to A. From there we start from the beginning. With input signal now synchronized as \$ a[n] \$, we can draw the diagram based on what we want.

From there you should be able to go from the state diagram to a state table, and then to a FSM circuit. You just need one DFF in your FSM to represent the two states. In the above example, A state and B state represent Q = 1 and Q = 0 respectively, but you can get an equally valid alternative FSM by switching the two states. If it isn't obvious how to get to the FSM circuit, follow some simple FSM tutorials until you get the hang of it.

The output of the FSM above will be \$a[n] \cdot \overline{a[n-1]}\$. This means you only output a 1-cycle pulse when there is a 0-to-1 transition in the input signal.

One final note is that if you can't tolerate errors during start up, you will need to add a reset to your three DFFs. Otherwise, the design above is guaranteed to stabilize to the correct output after three clock cycles after power on.

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