VHDL Counter does not update when desired

countervhdl

For a project I am working on, I require a counter whose value increases as soon as the increment control goes high (i.e. on the rising edge). However, I have had trouble implementing this in VHDL.

Here is some code that I have written:

IF Reset='1' THEN
        count := 0; -- Asynchronous reset
    ELSIF rising_edge(clock) THEN
        IF Enable = '1' THEN
            count := count+1; -- Increment
        END IF;
    END IF;
    q <= std_logic_vector(to_unsigned(count,12));

Here is the ModelSim simulation waveform:
enter image description here

As you can see, 'q' is only updated one clock cycle AFTER the Enable input goes high. I want q to increment as soon as Enable goes high. Is there a way to do this?

Best Answer

Everything is fine, when rising edge appears, the signal must be stable, not rising by itself. You will encounter this k7nd of problem later, when the logic you build will not propagate the signal fast enough and the output will not be ready before your next clock.

So foe now in modelsim make "enable" stable somewhere in the middle of your previous clock cycle.

Related Solutions

Electronic – CPLD best practice for resetting a counter

It sounds like you don't have an external reset signal to respond to, you just want to count to some number then go to zero as the next step. You could consider this a mod n counter, where n is one more than the maximum count in your counter.

So I'm not sure what you mean about "losing a signal" while doing the reset. If you had a 3-digit decimal counter and it rolled over from 999 to 000, you wouldn't consider it as "losing a signal", it would just be counting to the next value in mod-1000 arithmetic.

So if you do

always @(posedge clock) begin
    if (counter == some_number) begin
         counter <= 0;
    end
    else begin
        counter <= counter + 1;
    end
end

You'll have a counter that counts continuously in mod-some_number+1 arithmetic. Alternately you could say it counts to some_number, then resets to zero without ever "losing" a clock pulse.

If some_number+1 happens to be a power of 2, you don't even need the reset condition in your code. For example, for a mod-16 counter, you can just use a 4-bit counter, and the synthesized logic will count continuously and repeatedly from 0 to 15.

Electronic – Why is the simple counter VHDL not working? Where did the signals go

the rising_edge() parameter is only really for clock signals. One option would be the following:

clk_proc: process( clk, switch1, switch0 )
begin
    if switch1 = '1' then
        counter <= ( others => '0' );
    elseif rising_edge( clk ) then
        if switch0 = '1' then
            counter <= counter + 1;
        end if;
    end if;
end process;

This is known as an asynchronously reset process, which means that it'll reset the counter whenever reset (switch1) is high, regardless of clock state. A synchronously reset process would look the same as your second example:

clk_proc: process( clk, switch1, switch0 )
begin
    if rising_edge( clk ) then
        if switch1 = '1' then
            counter <= ( others => '0' );
        elsif switch0 = '1' then
            counter <= counter + 1;
        end if;
    end if;
end process;

You did state though that your second example didn't work as expected. My suspicion is that this is because the signals driving it are switches rather than clocked logic signals. Switches don't actually switch instantaneously, instead bouncing between on and off a few times before settling. You need to implement some sort of debounce process to produce a signal which is synchronous with your clock and can control your timer.

It's also worth mentioning that FPGA design is a lot easier if you simulate stuff first. Xilinx ISE includes a simulator - create a testbench and use it! That lets you easily see what's happening in your implementation before you ever get near hardware.

Best Answer

Related Solutions

Electronic – CPLD best practice for resetting a counter

Electronic – Why is the simple counter VHDL not working? Where did the signals go

Related Topic