vhdl code bug counter with debouncing of push button - vhdl

Question

I need to implement counter to 100 that increase his count every push button press, it has debouncing circuit using rising edge detector, I got mistakes in the simulation, the counter increases without syncing the push press button. I’m not sure where in the problem, please help me.
the clk is 100Mhz
here is the code:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.numeric_std.all;
use IEEE.std_logic_unsigned.all;
entity counter is
Port ( clk : in STD_LOGIC;
reset : in STD_LOGIC;
button : in STD_LOGIC;
count : out STD_LOGIC_VECTOR (6 downto 0)
);
end counter;
architecture Behavioral of counter is
signal debounced_button : std_logic;
signal prev_debounced_button : std_logic := '0';
signal counter_value : unsigned(6 downto 0) := (others => '0');
begin
-- Debounce the button signal using a rising edge detector
process (clk)
begin
if rising_edge(clk) then
if button = '1' and prev_debounced_button = '0' then
debounced_button <= '1';
else
debounced_button <= '0';
end if;
prev_debounced_button <= debounced_button;
end if;
end process;
-- Count up when the button is pressed
process (clk, reset)
begin
if reset = '1' then
counter_value <= (others => '0');
elsif rising_edge(clk) then
if debounced_button = '1' then
if counter_value = 100 then
counter_value <= (others => '0');
else
counter_value <= counter_value + 1;
end if;
end if;
end if;
end process;
-- Convert the counter value to a std_logic_vector for output
count <= std_logic_vector(counter_value);
end Behavioral;
--test bench:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.numeric_std.all;
entity counter_tb is
end counter_tb;
architecture Behavioral of counter_tb is
component counter
Port ( clk : in STD_LOGIC;
reset : in STD_LOGIC;
button : in STD_LOGIC;
count : out STD_LOGIC_VECTOR (6 downto 0)
);
end component;
signal clk : std_logic := '0';
signal reset : std_logic := '0';
signal button : std_logic := '0';
signal count : std_logic_vector(6 downto 0);
-- Stimulus process to generate clock and input signals
begin
uut: counter port map (
clk => clk,
reset => reset,
button => button,
count => count
);
clk_gen: process
begin
clk <= '0';
wait for 5 ns;
clk <= '1';
wait for 5 ns;
end process clk_gen;
stim_proc: process
begin
-- hold reset state for 100 ns.
reset <= '1';
wait for 20 ns;
reset <= '0';
wait;
end process;
process
begin
button <= '0';
wait for 40ns;
button <='1';
wait for 40ns;
button <= '0';
wait for 40ns;
button <='1';
wait for 40ns;
button <= '0';
wait for 40ns;
button <='1';
wait for 40ns;
end process;
end Behavioral;
I think I have problem in the test bench, I'm not sure
the simulation attachedenter image description here

Answer 1

You have two processes. The second process is a simple counter with an asynchronous reset -- no issues here. But let's look at the first.
process(clk)
begin
if rising_edge(clk) then
if button = '1' and prev_debounced_button = '0' then
debounced_button <= '1';
else
debounced_button <= '0';
end if;
prev_debounced_button <= debounced_button;
end if;
end process;
You have three signals, which I'll call button, debounced and prev. Note that they're signals, declared at the architecture level, and not variables within the process. Signals and variables are fundamentally different, as we'll see.
You also declare in the process' sensitivity list that it is sensitive only to clk. The simulator will only run this process whenever clk changes.
On the first rising edge of the clock, this process checks if the button is pressed, and if prev is zero. If so, it sets debounced to 1, else, it's set to 0. But debounced is a signal, which in this process is both being set and used. In a real system, this is called a race condition, and it's indeterminate which operation happens first. Your simulator handles this by always using the value of the signal in the previous time step. At time t-1, debounced was 0, so any statement that uses debounced at time t will use 0. Even if debounced is being changed to 1.
In other words, you have button high, debounced was just set high, and prev stays low.
On the second rising edge of the clock, it's likely buttonis still high as button presses last on the order of a million clock cycles. Since prev is still 0, debounced stays at 1, but this time the last debounced was 1 so prev is now set to 1.
Third rising edge, debounced goes to 0, since prev is now 1. prev stays 1.
Fourth rising edge, prev is still reading as 1, so debounced stays 0. prev now reads the old debounced and is now set to zero.
Fifth rising edge, prev reads as zero, so debounced goes to 1. But prev stays at 0 until the next tick.
This pattern continues as long as button is pressed. Once button goes to 0, then debounced is guaranteed to go to 0 on the next rising edge, and prev will go to 0 on the following tick.
In other words, debounced goes 1-1-0-0-1-1-0-0... oscillating at half the clock frequency for as long as the button is pressed. This isn't a debouncer. It's just using a button to turn on an oscillator. Any time button is 1, debounced_button will toggle; any time button is 0, debounced stays 0.
It's worth noting at this time that the second process uses debounced_button.
On to the simulation. Your system starts with previous at 0. At 40 ns, button goes high. What happens?
Nothing, at first -- you need a rising edge, which comes at 45 ns. Simultaneously, two processes run. The debouncer sees a button press, and sets debounced to 1. The counter uses the old value of debounced, and does nothing. prev uses the old value of debounced, and stays 0.
Next rising edge (55 ns), button is still high and prev is still low, so debounced stays at '1'. prev now goes to 1. Since debounced was high, the counter uses the old value, and now it increments.
65 ns: prev reads as 1, so debounced goes low. But since it was high a moment ago, the count increments again.
75 ns: debounced reads low, the counter doesn't increment.
85-115 ns: button is low, so debounced stays low, and the counter doesn't increment.
125 ns: button is high, so debounced goes high, but as should be obvious by now, the count won't increment.
Finally, note counter_value and count: count isn't being set inside a process with a sensitivity list, so it just changes immediately after counter_value, i.e. on the next simulator time step. Your processes run only when the simulator detects a change in a signal on its sensitivity list, and runs using a "snapshot" of the state of the signals at the start of the process. If you were using variables instead of signals, those are changed immediately and used identically to how sequential logic works in a standard programming language like C.
In reality, if you synthesize this design, you'll find that the behaviour is indeterminate. Your specific FPGA chip and the results of place and route will determine whether a signal is read before or after it's written.
When you have logic that changes a value and consumes it at the same time, the behaviour is indeterminate. You don't know which will happen first. I recommend having all outputs change on one clock edge (e.g. rising), and latch your inputs on the other clock edge (e.g. falling), to ensure that your inputs are stable before you try to use them.
Finally, debugging's a lot easier if you look at the internal signals. I simulated your code for 200 ns and got this:
Here, you can see exactly what's happening with prev and debounced, and immediately understand that there's a one-clock delay in the signal propagation.
Also, you can immediately see that your simulation's different from mine. It helps if you actually run the code you post here.