CPLD best practice for resetting a counter

Question

My application has a bog-standard count-until-a-certain-number-then-reset-the-counter section. My experienced friend tells me that when using actual chips, it's common to increment the counter on the rising edge of the clock and reset the counter on the falling edge. That way the designer has a lot of time to do what needs to be done before the next clock arrives.

But he's never used a CPLD and I wonder if this changes the rules. Or if his information is technically sensible but not practically needed.

My design has something like

always @(posedge clock) begin (increment the clock) end
always @(negedge clock) begin (reset the counter conditionally) end

I'm not trained at all in electrical engineering, I just read and dabble. But I can't let it rest when I don't feel I have a certain (n00b-level) understanding of what's going on.

I just read an example from a university course where the instructor didn't care about when the counter was reset. His design was something like:

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

This leads me to believe I'm over-engineering, the instructor is instructing not building an industrial app, or the synthesis process handles such things.

Of course I could try it in the simulator or actually plop it into the CPLD. Eventually this is going to be driving a powerful machine and it's got to work every time. I can't have an edge case where the machine misbehaves.

EDIT - more context. While it may not matter with respect to the answer, I am counting pulses generated by an encoder attached to a rotating spindle. I have to count every one of them, and I can't lose any.

EDIT 2 - example of a loop that increments a counter, then on some condition, changes it.

module slow_count(
    input clk,
    output reg [3:0] count
    );

    reg[19:0] snooze = 0;
    always @(posedge clk) begin
        snooze = snooze + 1;            // Set the counter
        if (snooze == 1000000) begin
            snooze = 0;             // And change it here
            count = count + 1;
            if (count == 10) count = 0;
            end
        end

endmodule

Answer 1

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.

Answer 2

If there's no reason to do otherwise, I always clear the counter on the next positive edge, assuming the counter is positive edge triggered. This keeps the time at each value constant, which may be important if the counter shares a clock signal with and controls other blocks, and especially frequency dividers. As always, synchronous operations are your friend. Your university example is good practice in my opinion.

Answer 3

If you don't need to reset the counter asynchronously, then the counter should simply determine on each clock cycle what the next clock value should be, so everything runs off the same clock edge. If you do need to reset the counter asynchronously, there are a variety of approaches which may be used based upon what is known about the timing of the reset input (most notably, whether there is any possibility that the reset signal might be released near a clock edge, and/or any possibility of "runt" reset pulse).

The most robust way to have a counter reset asynchronously is to have a sequence of three flip flops which are operated by the main clock, and have the first one by asynchronously reset by the master reset input. The data input to the first flop should be high when its output is high and either the second is high or the third is low, or when all three flops are low. The counter itself should not be asynchronously reset, but should instead load itself with an initial value whenever the third flip flop is low. The outputs from the counter should be asynchronously "AND"ed with the "and" of the three flip flops before driving downstream circuitry.

Using such an approach, any proper-length reset will cause the outputs to go low asynchronously. A runt reset pulse may cause the count outputs of the overall circuit to go momentarily unstable, but they will either reset cleanly or will within two cycles revert to the original count sequence. As described, there will be few cycles delay between releasing reset and observing the first count; such a delay may be eliminated by adding some extra logic between the counter and the circuits fed thereby, and by having the counter itself loaded with a non-zero value. Effectively, the first few counts following a reset would be handled by the flip flops rather than the counter. A runt reset pulse may cause those first few counts to appear oddly, but counts after them would be fine.