Frage

I was wondering why this doesn't work in my final design:

process (clk_in, reset, start)
begin
    if (reset = '1') then
        init_counter          <= '0';
        init_counter_done     <= '0';
    elsif rising_edge(clk_in) then
        if (start = '1' and init_counter_done = '0') then
            init_counter      <= '1';
            init_counter_done <= '1';
        end if;
        if (init_counter = '1') then
            init_counter      <= '0';
        end if;
    end if;
end process;

My idea is that when start changes state (from 0 to 1) init_counter should become 1 for one clock cycle. It doesn't seem to work though.

War es hilfreich?

Lösung

If you can tolerate the delay/latency, I would recommend a small adjustment as follows:

process (clk_in, reset)
begin
    if (reset = '1') then
        init_counter          <= '0';
        init_counter_done     <= '0';
        start_d               <= '0';
    elsif rising_edge(clk_in) then
        start_d <= start;
        if (start = '1' and start_d = '0' and init_counter_done = '0') then
            init_counter      <= '1';
            init_counter_done <= '1';
        else
            init_counter      <= '0';
        end if;
    end if;
end process;

This will keep your process purely synchronous. Previously it was slightly "confusing" (and possibly so to the tools) since "start" was in the sensitivity list, but your outputs would only update on the rising clock edge.

If this still doesn't work, can you clarify if it doesn't work in simulation or in hardware? If it does not work in hardware, possibly you need to debounce your start signal?

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top