Synchronous vs asynchronous counters: Question bank

Before we start, three words this page leans on, defined from zero so no line surprises you:

True or false — justify

Ripple counters are called "asynchronous" because their outputs are never aligned in time.

Half-true framing, but the name comes from the clock wiring, not the outputs. Only FF0 sees the master clock; the rest are clocked by the previous output, so edges arrive one-after-another — that staggering is what "asynchronous" refers to.

A synchronous counter has zero propagation delay because all flip-flops fire together.

False. Every flip-flop still has its own

t_{p d}

; firing together means the delays overlap instead of adding, so total settle is one

t_{p d}

(plus gate delay), not zero.

Adding more flip-flops to a ripple counter raises its maximum clock frequency.

False. More stages means a bigger division ratio but a longer settle chain:

f_{m a x} = 1/ (n t_{p d})

falls as

n

grows. Bigger ripple counter = slower to settle.

A single T flip-flop with

T = 1

divides its clock frequency by two.

True. One output cycle (0→1→0) needs two toggles, and each toggle needs one edge, so two input edges = one output cycle ⇒

f_{out} = f_{clk} /2

. This is the basis of Frequency division.

In a synchronous up-counter, bit

k

toggles whenever bit

k - 1

is 1.

False. It toggles only when all lower bits are 1:

T_{k} = Q_{0} Q_{1} \dots Q_{k - 1}

. Requiring just the adjacent bit is the ripple clocking rule, not the synchronous toggle logic.

Ripple counters need no AND gates.

True. Each later flip-flop is simply clocked by the previous output — the "carry" is carried by the clock wiring itself, so no gates are needed to decide when to toggle.

Synchronous counters are glitch-free because their flip-flops are higher quality.

False. The flip-flops are ordinary. Glitches vanish because all bits change on the same edge, so no intermediate staggered states exist to be briefly displayed.

Both counter families follow the exact same state sequence

0, 1, 2, \dots

True. Wiring differs, counting doesn't. A 4-bit up-counter of either type marches through the same binary states; only when the bits settle (and whether wrong transients flash) differs.

Spot the error

f_{m a x}^{sync} = 1/ (n t_{p d})

, so a 4-bit sync counter tops out at

1/ (4 \cdot 10 ns) = 25

MHz."

Wrong formula. The

n t_{p d}

chain is the ripple limit. Synchronous is

\approx 1/ (t_{p d} + t_{AND} + t_{setup})

— independent of

n

, so far faster than 25 MHz for the same chip.

"For a divide-by-16, I need 16 flip-flops."

Error: each flip-flop divides by 2, so you need

n

where

2^{n} = 16

, i.e.

n = 4

flip-flops, not 16.

"Bit 3's toggle logic in a sync up-counter is

T_{3} = Q_{3}

Error. A bit's toggle can't depend on itself as the carry condition. It is

T_{3} = Q_{2} Q_{1} Q_{0}

— the AND of all lower bits — which is true only at state

0111 \to 1000

"Since the outputs of a synchronous counter are perfectly aligned, real hardware has no timing problems."

Error. Perfect alignment assumes the clock reaches every flip-flop at the same instant. In real chips the clock arrives at slightly different times — Clock skew — which can break the intended simultaneity.

"A ripple counter clocked faster than

1/ (n t_{p d})

just runs faster."

Error. Beyond that limit the chain never finishes settling before the next edge, so the displayed count is never a valid number — it's continuously mid-ripple, i.e. garbage.

"The transient values a ripple counter shows (like

0110, 0100

during

0111 \to 1000

) are illegal states the FFs shouldn't produce."

Error. They are perfectly legal, real states — just briefly visited because the bits settle at different times. They are decoding glitches, not faults.

Why questions

Why does a ripple counter's delay add up while a synchronous counter's does not?

In ripple, FF

k

's clock edge can't arrive until FF

k - 1

has settled, so waits stack in series (

n t_{p d}

). In sync, every clock edge arrives at once, so the

t_{p d}

waits happen in parallel and overlap into one.

Why does synchronous counting need the AND of all lower bits, not just the previous one?

Because all flip-flops share one clock, each must self-decide whether to toggle. The binary carry into position

k

exists only when every less-significant digit is 1 — that condition is a product (AND) of all lower

Q_{i}

. See Carry lookahead.

Why is a synchronous counter's max frequency (roughly) independent of the number of bits?

Since all flip-flops clock simultaneously, the critical path is one flip-flop's

t_{p d}

plus the gate delay computing its toggle input — neither grows just because more bits sit alongside (given a lookahead-style AND tree).

Why does a T flip-flop with

T = 1

act as a frequency divider at all?

Toggling on each edge means the output holds each level across a whole input period, so it takes two input edges to complete one output cycle — mechanically halving the frequency.

Why do we prefer ripple counters despite their glitches?

They are the simplest possible: no AND gates, minimal wiring, lowest power. When speed and glitch-freedom don't matter (e.g. slow Frequency division), simplicity wins.

Why can Clock skew undermine a "synchronous" counter's promise?

The whole benefit rests on every flip-flop seeing the edge at the same instant. If the clock wire's routing makes the edge arrive late at some flip-flops, those bits act on stale data and the intended simultaneity breaks.

Edge cases

What does a 1-flip-flop ripple counter do, and is it "slow"?

It's just a single T flip-flop dividing by 2. With

n = 1

t_{settle} = 1 \cdot t_{p d}

— no chain, so it's exactly as fast as a synchronous 1-bit counter. The ripple penalty only appears for

n \geq 2

What is the settle time of a synchronous counter with only one flip-flop?

About one

t_{p d}

— and since

T_{0} = 1

needs no AND gate, there's essentially no gate delay either. Sync and async are identical at

n = 1

If a modulo-N counter resets before reaching

2^{n} - 1

, does the ripple settle formula still apply?

The worst-case

n t_{p d}

still bounds the longest ripple (e.g. the all-ones→all-zeros transition on reset), so use it as the safe upper limit even though not every count triggers a full-length ripple.

What happens at the wrap-around state

1111 \to 0000

in a ripple counter?

This is the worst ripple: every bit must toggle in sequence, so the delay chain is maximal and the most decoding glitches appear. It's precisely the transition the

n t_{p d}

bound is built around.

At the wrap-around

1111 \to 0000

in a synchronous up-counter, what is each

T_{k}

All are 1:

T_{0} = 1

and

T_{k} = Q_{0} \dots Q_{k - 1} = 1 \cdot 1 \dots 1 = 1

since every lower bit is 1. So every flip-flop toggles on that single shared edge — clean, simultaneous, no transient.

Is a counter with

n = 0

flip-flops meaningful?

No — with zero flip-flops there is no state to store, so nothing counts. The formulas (

n t_{p d}

2^{n}

states) still degenerate sensibly:

2^{0} = 1

state, meaning "always the empty count," which is just a wire, not a counter.

Connections

Parent: Sync vs async counters
T flip-flop · JK flip-flop — the toggling core each trap relies on
Propagation delay — the source of ripple's stacked delay
Carry lookahead — why the AND-tree keeps sync fast
Clock skew — the real-world limit on true simultaneity
Modulo-N counters · Frequency division — edge-case behaviours above