Ripple Counter Explorer

Set any modulus from 2 to 16 and clock it by hand or automatically. Each stage toggles only after the one before it settles, and the animation shows that domino deliberately — because the accumulating delay is the entire reason synchronous counters exist.

Clock the counter and watch the ripple propagate through the flip-flop chain — each stage toggles only after the previous one finishes.

MOD-83 flip-flops · counts 0–7

216

Ripple counter — watch each FF toggle in sequence

Current count

= 0

Next state (after clock)

= 1

Speedmed

Ripple delay

45 ns

3 FFs × 15 ns

Max frequency

22.2 MHz

f_max = 1 / (3 × 15 ns)

Clock count

of MOD-8 cycle

Propagation delay accumulation

FF0

15 ns

FF1

30 ns

FF2

45 ns

Frequency division (1 MHz input)

Stage	Frequency	Division
CLK (input)	1 MHz	—
Q0	500 kHz	÷ 2
Q1	250 kHz	÷ 4
Q2	125 kHz	÷ 8

State table (MOD-8)

Decimal	Binary
0	000
1	001
2	010
3	011
4	100
5	101
6	110
7	111

Each stage clocks the next

An asynchronous — or ripple — counter is a chain of toggle flip-flops where only the first sees the real clock. Every other stage is clocked by the output of the one before it. That is why it is so cheap: no steering logic at all, just flip-flops in a row. And it counts correctly, because a stage toggling once for every two toggles of its predecessor is exactly binary counting.

Each stage divides the frequency by two

Q0 changes on every input clock, so it runs at half the input frequency. Q1 changes on every Q0 fall, so it is a quarter. The divider table under the widget makes this concrete: from a 1 MHz clock you get 500 kHz, 250 kHz, 125 kHz and so on. A ripple counter used purely as a divider is a genuinely good choice — the timing problems below only matter when you decode the count.

Why the delay accumulates, and what it breaks

The last stage cannot change until the ripple has passed through every stage before it, so the settling time is n × t_pd. During that window the counter shows transient values that were never meant to exist — going from 0111 to 1000 momentarily reads 0110, then 0100, then 0000. Decode the outputs with a gate and those glitches appear on its output as real, short pulses.

Getting a modulus that is not a power of two

A chain of n flip-flops naturally counts 2ⁿ states. For a MOD-10 counter you take four stages, decode the count of 10, and feed that back to the asynchronous clear — the counter reaches 10 for a few nanoseconds and is wiped back to zero. That brief illegal state is real, and it is why a synchronous counter with proper next-state logic is preferred wherever the count is actually used.

Learn more → Asynchronous Counters — Learn

Quick experiments

Watch the ripple cross every stage at once. Set MOD-16 and clock from 0111 to 1000. All four stages have to toggle, so the domino runs the full length of the chain — the worst case, and the moment when the counter briefly displays values it should never show.
Find the cheapest transition. Clock from 0000 to 0001. Only the first stage moves and the count is stable almost immediately. Ripple delay is not a fixed cost per clock — it depends entirely on how many low bits are rolling over.
Read the divider chain. Look at the frequency table with MOD-16 selected. From 1 MHz in you get 500 kHz, 250 kHz, 125 kHz and 62.5 kHz. Each flip-flop is an exact divide-by-two, which is what makes ripple counters good clock dividers even though they are poor counters.
Set a non-power-of-two modulus. Choose MOD-10. It still needs four flip-flops, because three only reach 8. The tenth count is detected and cleared, which is why MOD-10 is a decade counter built on a 4-bit chain rather than a 'MOD-10 chain'.
Run it fast and watch the glitches persist. Turn on auto-clock at the fastest speed. The transient states do not go away at higher frequency — they occupy the same absolute nanoseconds but a larger share of each period, which is exactly why ripple counters have a low maximum usable frequency.

Formula reference

States from n flip-flops: $\text{states} = 2^n$
4 stages give 16 counts, 0 to 15.
Flip-flops needed for a modulus: $n = \lceil \log_2 M \rceil$
MOD-10 needs 4, because 3 only reach 8.
Frequency at stage k: $f_k = \frac{f_{clk}}{2^{k+1}}$
Q0 is half the input, Q1 a quarter, and so on.
Worst-case settling time: $t_{settle} = n \times t_{pd}$
The ripple must cross every stage. 4 stages at 15 ns is 60 ns.
Maximum usable clock: $f_{max} = \frac{1}{n \times t_{pd}}$
Compare a synchronous counter, where n does not appear at all.

Symbol	Meaning	Unit
$n$	Number of flip-flop stages	—
$M$	Modulus — counts before wrapping	—
$t_{pd}$	Propagation delay of one stage	ns
$f_{clk}$	Input clock frequency	Hz

Common mistakes

Decoding a ripple counter's outputs with a plain gate.
During the ripple the counter passes through states it never logically occupies, and a decoder will produce short spurious pulses on those. Either strobe the decoder after the counter has settled, or use a synchronous counter where all stages change together.
Assuming the maximum clock frequency is set by one flip-flop.
It is set by the whole chain — n × t_pd. Adding a fifth stage to a 4-stage counter makes it 25 % slower, whereas a synchronous counter's speed is independent of its width.
Expecting three flip-flops to give a MOD-10 counter.
Three stages reach 8 states, not 10. You need ⌈log₂10⌉ = 4, then detect the count of 10 and clear back to zero. The extra states are unused, not unavailable.
Treating the clear-on-decode glitch as harmless.
The counter genuinely reaches the terminal count for a few nanoseconds before the clear takes effect. If anything else in the system samples during that sliver it will see a count that should not exist — a classic source of intermittent faults.
Calling a ripple counter synchronous because it has a clock input.
Only the first stage is clocked by it. The rest are clocked by their neighbours, which is precisely what makes the counter asynchronous and gives it the accumulating delay. A synchronous counter feeds the same clock to every flip-flop.

Frequently asked questions

What is a ripple counter?

A chain of toggle flip-flops in which only the first stage sees the real clock and every other stage is clocked by the output of the one before it. That makes it very cheap in gates, because there is no steering logic at all, but the stages do not change simultaneously.

Why is it called asynchronous?

Because the flip-flops are not all clocked by the same signal. Each one toggles only after its predecessor has settled, so a change ripples along the chain instead of happening at one instant. A synchronous counter feeds the same clock to every flip-flop.

How many flip-flops do I need for a MOD-10 counter?

Four. Three stages only reach eight states, so you take four, detect the count of ten, and feed that back to the asynchronous clear. The counter briefly reaches ten before being wiped back to zero.

Why should you not decode a ripple counter's outputs directly?

While the ripple is travelling the counter passes through states it never logically occupies, such as showing 0110 and 0100 on the way from 0111 to 1000. A decoder gate turns those transients into real short pulses on its output.

How does a ripple counter divide frequency?

Each stage toggles once for every two toggles of the one before it, so each output is exactly half the frequency of the previous one. From a 1 megahertz clock the stages give 500, 250, 125 and 62.5 kilohertz, which makes ripple counters good clock dividers even where they are poor counters.