10.2 Asynchronous / Ripple Counter

Explain how a ripple counter's cascaded flip-flops produce a rippling propagation delay, calculate the resulting frequency-division behavior, and identify the glitch risk it creates for decode logic.

An asynchronous (ripple) counter builds a multi-bit counting sequence out of toggle flip-flops chained so that each flip-flop is clocked not by the system's master clock, but by the output of the flip-flop before it — only the very first stage receives the actual external clock. It exists as the simplest possible way to build a binary counter, using the fewest gates, because each flip-flop toggling exactly once per pair of toggles of the previous stage is naturally a divide-by-2 operation, chained together to divide by 2, 4, 8, and so on.

Core concept: only the first stage sees the real clock

In a ripple counter, flip-flop FF0 is the only stage clocked directly by the external clock signal. FF0 is wired (typically as a T flip-flop, or a JK flip-flop with J=K=1, which toggles on every active clock edge) so that its own output Q0 toggles once per input clock edge. FF1 is then clocked not by the external clock, but by Q0 itself — so FF1 toggles once every time Q0 transitions in the triggering direction, which happens once every two external clock edges. FF2 is clocked by Q1, toggling once every four external clock edges, and so on down the chain.

Because each stage only begins responding after the previous stage's output has actually changed, and every real flip-flop has a nonzero propagation delay from its clock edge to its output changing, a change at the input ripples through the chain one propagation delay at a time rather than all stages updating at the exact same instant — this rippling delay is what gives the ripple counter its name, and it is the direct cause of the spec's tricky point: the counter's intermediate outputs do not all change simultaneously, because each one waits for the stage before it to settle first.

• Only FF0 is clocked by the actual external clock; every other stage is clocked by the previous stage's Q output. • Each stage is a divide-by-2 relative to the stage before it — this chain is literally a frequency-division circuit. • Because stages trigger sequentially rather than simultaneously, transitions ripple through with a per-stage propagation delay.

Step-by-step working and the frequency-division formula

For a 3-bit negative-edge-triggered ripple up-counter, FF0 toggles on every falling edge of the external clock; FF1 toggles on every falling edge of Q0; FF2 toggles on every falling edge of Q1. Tracing this reveals that Q0 has exactly half the frequency of the input clock, Q1 has exactly one quarter, and Q2 has exactly one eighth — in general, stage k (0-indexed) divides the input clock frequency by 2^(k+1). This is precisely why ripple counters are the standard building block for simple digital frequency dividers.

The total propagation delay from the external clock edge to the MSB (the last stage) finally settling is the sum of each stage's individual clock-to-Q delay, roughly n times a single flip-flop's propagation delay for an n-stage counter. This accumulating delay is the ripple counter's main limitation: it directly caps how fast the counter can be clocked before the ripple delay from one clock edge overruns the period until the next one, which is why wide ripple counters are much slower than synchronous counters of the same width (Topic 10.3).

Practical application, real-world use, and common mistake

Because each stage of a ripple counter is inherently a divide-by-2 circuit, chaining several stages together is the simplest way to build a frequency divider — for example, dividing a crystal oscillator's output down by a power of two to derive a slower clock domain for a less speed-critical part of a circuit, or building an inexpensive frequency counter or simple digital clock where the small ripple delay is not operationally significant.

The most common and consequential mistake is feeding a ripple counter's outputs directly into a combinational decoder (for instance, logic that detects 'the count equals 5' to drive some downstream action) without accounting for the ripple delay. Because the bits don't all change at exactly the same instant, the counter can transiently pass through unintended intermediate binary patterns while rippling from one valid state to the next — for example, a transition like 011 -> 100 can very briefly glitch through states such as 010 or 000 as each bit updates one propagation delay after the one before it — and a fast combinational decoder watching those outputs can catch and act on that transient glitch state before the counter settles.

Ripple counter notation

Only the first flip-flop is driven by the real external clock; every later stage is driven by the previous stage's output, not the master clock. This lack of a shared clock is exactly what 'asynchronous' means in 'asynchronous counter' — it is not the same 'asynchronous' as an asynchronous clear/preset input.

3-bit ripple up-counter (negative-edge-triggered T flip-flops):

  CLK ---T Q--- Q0 ---T Q--- Q1 ---T Q--- Q2
          FF0            FF1            FF2

FF0 clocked by:  external CLK
FF1 clocked by:  Q0
FF2 clocked by:  Q1

Frequency at stage k (0-indexed):  f(CLK) / 2^(k+1)
Total MSB settle delay (n stages): approx. n * t_pd (per-flip-flop propagation delay)

Code Examples

Each stage divides its own input frequency by exactly 2, so after n stages the output frequency is the original clock divided by 2^n. Here, the 3rd stage (Q2) outputs a clean 1 MHz signal derived entirely from the 8 MHz input clock, with no other components needed. Expected result: Q2 provides an 8 MHz / 8 = 1 MHz divided clock output.

Stage k output frequency = input clock frequency / 2^(k+1).

Input clock frequency: 8 MHz

Q0 (FF0, toggles every input clock edge):        8 MHz / 2  = 4 MHz
Q1 (FF1, toggles every Q0 transition):           8 MHz / 4  = 2 MHz
Q2 (FF2, toggles every Q1 transition):           8 MHz / 8  = 1 MHz

Ripple counter: sequential, not simultaneous, propagation

Each stage waits for the previous stage's output to actually change before it can respond — hence 'ripple.'

CLK -> [FF0] -Q0-> [FF1] -Q1-> [FF2] -Q2->
         |t_pd    |t_pd    |t_pd
         v        v        v
     Q0 settles  Q1 settles (after  Q2 settles (after
     ~1 t_pd      Q0 changes,        Q1 changes,
     after CLK    ~2 t_pd total)     ~3 t_pd total)

Important Rules

Only the first flip-flop in a ripple counter receives the actual external clock; every subsequent stage is clocked by the previous stage's output.

Stage k (0-indexed) of a ripple counter divides the input clock frequency by 2^(k+1) — ripple counters are inherently frequency dividers.

Total settling delay from clock edge to the MSB stabilizing grows with the number of stages (roughly n times one flip-flop's propagation delay), capping the counter's maximum reliable clock frequency.

Simple frequency dividers

Ripple counters are the standard low-cost way to divide a fast oscillator's frequency down by a power of two for a slower, less speed-critical clock domain, and they appear in inexpensive digital clocks, simple frequency counters, and any circuit where the small ripple delay is not a practical problem and minimizing gate count matters more than achieving the highest possible speed.

Wiring a fast combinational decoder directly to a ripple counter's outputs and trusting it to react correctly the instant the count changes.

Account for the ripple delay: either allow settling time before sampling the decoded output, or use a synchronous counter (Topic 10.3) when glitch-free decoding is required, since a ripple counter's bits do not all change at the same instant.

Because each bit change ripples in sequentially with a real propagation delay, the counter can transiently pass through unintended states during a transition (e.g., glitching through 010 or 000 on a 011->100 change) — a decoder sampled at the wrong instant can misfire on one of these transient, incorrect states.

[tricky-problem] In a ripple counter, why don't all the output bits change at exactly the same instant when the count transitions from one value to the next? A. Because ripple counters use a slower clock than synchronous counters B. Because only the first stage is clocked by the external clock; every later stage is clocked by the previous stage's output, so each bit must wait for the stage before it to actually change before it can respond, one propagation delay at a time C. Because ripple counters randomly skip bits during some transitions D. Because ripple counters require a manual reset between every count

B. Because only the first stage is clocked by the external clock; every later stage is clocked by the previous stage's output, so each bit must wait for the stage before it to actually change before it can respond, one propagation delay at a time — This is exactly the spec's tricky point for ripple counters: because each flip-flop after the first is triggered by the previous stage's output rather than a shared master clock, a change has to propagate — ripple — through the chain, with each stage settling only after the one before it, one propagation delay at a time, rather than all bits updating simultaneously.

[interview] Why is a ripple counter generally slower (lower maximum clock frequency) than a synchronous counter with the same number of bits? A. Ripple counters use larger flip-flops that are inherently slower B. A ripple counter's total settling delay grows with the number of stages, since each stage's clock depends on the previous stage actually changing first, while a synchronous counter's delay is roughly just one flip-flop delay plus one gate delay regardless of width C. Ripple counters cannot be built with more than 4 bits D. There is no actual speed difference between the two

B. A ripple counter's total settling delay grows with the number of stages, since each stage's clock depends on the previous stage actually changing first, while a synchronous counter's delay is roughly just one flip-flop delay plus one gate delay regardless of width — A ripple counter's worst-case settling time scales with the number of stages (each stage waits on the one before it), while a synchronous counter clocks every stage simultaneously from one shared clock, with only the combinational next-state logic's delay added on top — so a synchronous counter's maximum speed does not degrade nearly as much as bit-width grows.

A 4-stage ripple counter is built from T flip-flops, each with a propagation delay of 10 ns. Approximately how long after a qualifying clock edge on FF0 will the MSB (the 4th stage) have fully settled to its new value in the worst case, and what maximum clock period does this imply if you need the counter fully settled before the next clock edge arrives?

Worst-case MSB settling delay ~= 4 stages x 10 ns = 40 ns after the triggering edge. To guarantee the counter is fully settled before the next active clock edge, the clock period must be at least 40 ns, capping the maximum clock frequency at roughly 1 / 40 ns = 25 MHz for this particular 4-stage chain.

Worst-case settling time is roughly the sum of each stage's individual propagation delay, since each stage must wait for the one before it.