Interview Traps: Clock-Domain Synchronizers, Ripple Counters, and Ring/Johnson Counters

Explain precisely why two-flip-flop synchronizers are the standard defense against metastability, why ripple counters produce decoding glitches that synchronous counters don't, and derive the exact flip-flop counts and state-cycle lengths for decade and Johnson counters instead of quoting them from memory.

This cluster moves from the timing-hazard concepts in the previous lesson into their concrete circuit consequences: how you actually protect a system from metastability, and how counter architecture choices (ripple vs. synchronous, binary vs. twisted-ring) trade off simplicity against glitch-free, predictable behavior. Interviewers use these to check whether 'flip-flop count' and 'state count' answers come from an actual state-diagram or shift-register argument, or from rote memorization of a specific IC's datasheet.

Why are two flip-flops commonly used for synchronization?

When an asynchronous signal — one not aligned to the receiving system's clock, such as a button press or a signal crossing from another clock domain — is sampled directly by a flip-flop, there is a real chance the signal changes right at the sampling instant, violating setup or hold time and driving that flip-flop into metastability. A single flip-flop offers no guarantee that this metastable condition will have resolved to a valid 0 or 1 before its output is used by the rest of the circuit.

Chaining a second flip-flop, clocked by the same clock, directly after the first (a standard two-flip-flop synchronizer) gives the first flip-flop's potentially metastable output a full clock period to settle toward a valid logic level before the second flip-flop samples it. Because the probability of remaining unresolved decays exponentially with elapsed time, giving it one whole extra clock period before the value is used anywhere else in the design reduces the probability of a metastability failure propagating downstream by many orders of magnitude — though, being a probabilistic phenomenon, it is never reduced to mathematically exactly zero. At very high clock frequencies or in especially failure-sensitive designs, a third flip-flop stage is sometimes added for additional margin.

The trap answer is 'one flip-flop is fine if you just wait a cycle before using its output' — that's actually restating the two-flip-flop idea without the second flip-flop: without an actual second clocked stage, there's nothing physically forcing the 'wait' to happen at the same clock edge as the rest of the synchronous logic, and a single-flip-flop synchronizer remains a well-known, dangerous mistake precisely because it relies on one settling window instead of enforcing one via a second sampling stage.

Why does a ripple counter have decoding glitches?

A ripple (asynchronous) counter chains flip-flops so that each stage's clock input is driven by the output of the previous stage, rather than all stages sharing one common clock. This means the flip-flops do not all change state at the same instant — each stage's transition triggers the next stage's transition only after that stage's own propagation delay, so a multi-bit carry has to 'ripple' through the chain from the least-significant to the most-significant bit, exactly analogous to a ripple-carry adder's carry chain.

During that rippling window, the counter's output briefly passes through incorrect intermediate binary values before settling on the correct next count. For example, a 3-bit ripple counter going from 011 to 100 might transiently show 010, then 000, before finally reaching 100, because each bit flips in sequence rather than simultaneously. Any combinational decoding logic (such as a 1-of-N decoder) watching the counter's raw outputs during this transient window sees those intermediate, incorrect values and can produce brief, spurious output pulses that don't correspond to any real, intended count value.

The trap answer is 'the flip-flops are too slow,' which misattributes the cause to component speed rather than architecture. Even with arbitrarily fast (but still nonzero-delay) flip-flops, a ripple counter will always produce transient decoding glitches, because the fundamental issue is that bits change asynchronously relative to each other, not that any individual flip-flop is underperforming. A synchronous counter, where every flip-flop shares the same clock and all bits that need to change do so on the very same edge, does not have this problem.

Why does a Mod-10 (decade) counter require four flip-flops?

A Mod-10 (decade) counter must be able to represent 10 distinct states (typically 0 through 9) before it wraps back around. The number of flip-flops n in a binary counter determines how many distinct states it can represent: 2^n. With n=3 flip-flops, only 2^3=8 states (0-7) are available, which is not enough to count all 10 required values. With n=4 flip-flops, 2^4=16 states (0-15) are available, which is more than enough — so 4 is the minimum number of flip-flops whose state count (a power of 2) is at least 10.

Because 16 available states exceeds the 10 actually needed, a decade counter uses only states 0000 through 1001 (0-9) and includes extra reset/feedback logic that forces the counter back to 0000 as soon as it would otherwise reach 1010 (10), rather than letting it naturally count all the way to 1111 (15). The remaining six states (1010-1111) are simply skipped over by design, exactly mirroring the six wasted 4-bit codes discussed in BCD encoding.

The trap answer is 'because that's just how decade-counter ICs like the 7490 are designed' — treating it as an arbitrary industry convention rather than deriving it. The precise reasoning is a minimum-bits calculation: find the smallest n such that 2^n ≥ 10, which is n=4 (since 2^3=8 is insufficient and 2^4=16 is the next available power of 2), and then note that the unused states beyond 9 must be explicitly excluded via feedback/reset logic.

Why does a Johnson counter have 2n states?

A Johnson counter (also called a twisted-ring or switch-tail ring counter) is built from n flip-flops connected as a shift register, where the complement (inverted output) of the last flip-flop is fed back into the input of the first flip-flop. Because the fed-back value is inverted rather than passed through unchanged, the register does not return to its starting pattern after just n shifts, the way a plain ring counter (which feeds back the true, non-inverted output) would; instead, it takes exactly 2n shifts before the original starting pattern reappears.

Concretely, starting from all zeros (0000 for n=4), each shift inserts the complement of the last bit at the front: the sequence runs 0000, 1000, 1100, 1110, 1111 (n=4 shifts to fill with 1s), and then the inverted feedback starts inserting 0s: 0111, 0011, 0001, and finally back to 0000 — a full cycle of 2n=8 distinct states for n=4 flip-flops, exactly double the n states a plain ring counter with the same number of flip-flops would produce.

The trap answer is 'a Johnson counter counts twice as fast as a regular counter,' which confuses state-cycle length with speed — a Johnson counter isn't faster; it produces twice as many unique states from the same number of flip-flops purely because the inverted feedback doubles the shift-register's return-to-start period, which is also why each successive state differs from the previous one in exactly one bit (similar in spirit to Gray code), a useful property for glitch-tolerant sequencing and timing applications.

Two-flip-flop synchronizer and Johnson counter sequence

A plain ring counter (non-inverted feedback) with n flip-flops cycles through only n unique one-hot states; inverting the feedback (Johnson/twisted-ring counter) doubles the cycle length to 2n. Ripple counters produce transient glitches because stages change sequentially (asynchronously); synchronous counters, where every flip-flop shares one clock, change all relevant bits on the same edge and do not have this failure mode.

Two-flip-flop synchronizer:
  async_in --D--[FF1]--Q1--D--[FF2]--Q2--> synchronized output
              clk--^         clk--^        (same clock for both stages)

  FF1 may go metastable if async_in changes near clk edge.
  FF1's Q1 has one full clock period to resolve before FF2 samples it.
  FF2's Q2 is used by the rest of the synchronous design.

Decade counter minimum flip-flop count:
  Need >= 10 states  =>  smallest n with 2^n >= 10  =>  n = 4  (2^4=16 >= 10 > 2^3=8)
  States 1010-1111 (10-15) unused; feedback resets counter to 0000 after reaching 1001 (9)

Johnson counter (n=4 flip-flops), starting at 0000, inverted feedback:
  0000 -> 1000 -> 1100 -> 1110 -> 1111 -> 0111 -> 0011 -> 0001 -> 0000 (repeats)
  8 = 2n distinct states for n=4 flip-flops

Code Examples

Even though the counter eventually lands on the correct value (4), any logic combinationally decoding the raw Q2Q1Q0 lines during the propagation window sees a sequence of transient, wrong values. This is the precise mechanism of 'ripple counter decoding glitches,' and it is entirely a consequence of the asynchronous (stage-triggers-next-stage) clocking structure, not of any individual flip-flop malfunctioning.

3 -> 2 -> 0 -> 4, transient glitch values 2 and 0 appear briefly before the counter settles on the correct value 4

Common mistake: Assuming a ripple counter's *final* correct value means there's no problem — the final value is correct, but any downstream combinational logic reading the counter *during* the ripple window (which can easily happen if that logic is fast relative to the ripple delay) sees and can act on the glitch values.

3-bit ripple-up counter (Q2 Q1 Q0), each flip-flop toggled by the previous stage's output:

Starting state: Q2 Q1 Q0 = 0 1 1  (decimal 3)
Next correct state: 1 0 0  (decimal 4)

Actual transition, bit-by-bit, due to propagation delay:
  t0:            0 1 1   (3)   -- before the triggering clock edge
  t0 + delay1:   0 1 0   (2)   -- Q0 flips first (0->? actually toggles), Q1,Q2 not yet updated
  t0 + delay2:   0 0 0   (0)   -- Q1 then flips after seeing Q0's edge
  t0 + delay3:   1 0 0   (4)   -- Q2 finally flips after seeing Q1's edge -- correct value reached

A decoder watching these outputs briefly sees 2, then 0, before the correct 4 -- two
spurious, momentary decoded states that never should have appeared.

Ring counter vs. Johnson (twisted-ring) counter feedback

Inverting the feedback path (Johnson counter) exactly doubles the number of flip-flop-count states in the repeating cycle compared to a plain ring counter.

Plain ring counter (n=4), TRUE feedback, cycles through only n=4 states:
  [FF0]->[FF1]->[FF2]->[FF3]-+
     ^________________________|   (Q3 feeds back into FF0 input, uninverted)
  States: 1000 -> 0100 -> 0010 -> 0001 -> 1000 (repeats after 4 shifts)

Johnson counter (n=4), INVERTED feedback, cycles through 2n=8 states:
  [FF0]->[FF1]->[FF2]->[FF3]-+
     ^_________________NOT____|   (Q3' feeds back into FF0 input, inverted)
  States: 0000->1000->1100->1110->1111->0111->0011->0001->0000 (repeats after 8 shifts)

Why this matters beyond the interview

Two-flip-flop (or deeper) synchronizers are mandatory, standard practice anywhere an asynchronous or cross-clock-domain signal enters a synchronous design — button/switch inputs, reset signals from another chip, or any signal crossing between two independently clocked blocks on the same FPGA/ASIC — and under-designing one is a classic root cause of field failures that never show up in a simulator. Ripple counter glitches are why real synchronous designs (and the digital clocks/timers built from them) use synchronous counters, or add a register stage after a ripple counter to re-clock (and thus clean up) its output before decoding it. Johnson/ring counters are used in practice for simple sequencer and timing-control applications precisely because their single-bit-change-per-step property (like Gray code) avoids the decoding-glitch problem that a binary ripple counter has.

A ripple counter's decoding glitches happen because its flip-flops are lower quality or too slow compared to a synchronous counter's flip-flops.

Decoding glitches happen because each stage's clock input is driven by the previous stage's output, so bits change sequentially rather than simultaneously — even with ideal, arbitrarily fast flip-flops, a ripple counter still produces transient incorrect states while the carry ripples through, purely due to this asynchronous clocking architecture.

This distinction matters for the correct fix: swapping in faster flip-flops does not eliminate ripple glitches, only switching to a synchronous counter design (all flip-flops sharing one common clock) does.

Why is a two-flip-flop synchronizer used instead of relying on a single flip-flop when sampling an asynchronous input? A. A single flip-flop cannot be clocked at all by an asynchronous source B. The first flip-flop may go metastable if the input changes near a clock edge; the second flip-flop, clocked on the same edge, gives that potentially metastable value a full clock period to settle before it is sampled again, exponentially reducing (but not eliminating) the risk of metastability reaching the rest of the design C. Two flip-flops are needed to store both the rising and falling edge of the input D. It doubles the maximum clock frequency the design can run at

B. The first flip-flop may go metastable if the input changes near a clock edge; the second flip-flop, clocked on the same edge, gives that potentially metastable value a full clock period to settle before it is sampled again, exponentially reducing (but not eliminating) the risk of metastability reaching the rest of the design — A lone flip-flop sampling an asynchronous signal has no guarantee its output has resolved from a possible metastable state before that output is used elsewhere. A second flip-flop, clocked identically, effectively allocates one full clock period as a 'cooldown' for the first flip-flop's output to settle, which reduces (exponentially, though never to exactly zero) the chance a still-metastable value propagates into the rest of the synchronous logic.

What is the actual cause of decoding glitches in a ripple (asynchronous) counter? A. The flip-flops used are inherently lower-quality than those in synchronous counters B. Each flip-flop's clock is driven by the previous stage's output, so bits change sequentially rather than on one common edge, producing transient incorrect intermediate states while the change 'ripples' through the chain C. Ripple counters use combinational logic instead of flip-flops D. The counter's reset signal is asserted too frequently

B. Each flip-flop's clock is driven by the previous stage's output, so bits change sequentially rather than on one common edge, producing transient incorrect intermediate states while the change 'ripples' through the chain — In a ripple counter, each stage only toggles after seeing a transition on the previous stage's output, so a multi-bit change (like 011->100) happens bit-by-bit over several small delays rather than all at once. Any decoder reading the counter's outputs during that window can see (and act on) the transient, incorrect intermediate values — a structural consequence of asynchronous clocking, not of slow or faulty components.

Why does a Mod-10 (decade) counter require a minimum of 4 flip-flops? A. Because decade counters are standardized by IEEE to always use 4 bits B. Because 10 distinct states must be represented, and the smallest number of flip-flops n satisfying 2^n >= 10 is n=4 (since 2^3=8 is insufficient and 2^4=16 is the next available power of 2) C. Because BCD always requires exactly 4 flip-flops per counter regardless of the modulus D. Because 4 flip-flops guarantee glitch-free operation, unlike 3

B. Because 10 distinct states must be represented, and the smallest number of flip-flops n satisfying 2^n >= 10 is n=4 (since 2^3=8 is insufficient and 2^4=16 is the next available power of 2) — A binary counter with n flip-flops can represent 2^n states. Ten required states rule out n=3 (only 8 states available) and are satisfied by n=4 (16 states available, of which only 0-9 are used, with feedback logic resetting the counter before it would reach the six unused states 10-15).

Why does an n-flip-flop Johnson (twisted-ring) counter cycle through 2n states instead of n states? A. Because Johnson counters run at twice the clock frequency of ring counters B. Because the feedback from the last flip-flop to the first is inverted rather than passed through unchanged, so the register takes twice as many shifts (2n) before returning to its original starting pattern, compared to a plain ring counter's n-shift return with non-inverted feedback C. Because Johnson counters use twice as many flip-flops as a ring counter for the same state count D. Because each flip-flop in a Johnson counter stores two bits instead of one

B. Because the feedback from the last flip-flop to the first is inverted rather than passed through unchanged, so the register takes twice as many shifts (2n) before returning to its original starting pattern, compared to a plain ring counter's n-shift return with non-inverted feedback — A plain ring counter feeds the true (non-inverted) output of its last stage back to the first stage's input, returning to its starting pattern after exactly n shifts. A Johnson counter inverts that feedback, so the register must be shifted through twice as many distinct patterns — 2n — before the original starting state reappears, which is also why consecutive Johnson-counter states differ by exactly one bit, similar in spirit to Gray code.

You need a counter that cycles through exactly 12 unique one-hot-adjacent states (each state differing from the next by one bit) for a simple traffic-light-style sequencer, and you want to build it as a Johnson (twisted-ring) counter. How many flip-flops are required, and what is the resulting full state-cycle length? Is 12 achievable exactly, and if not, what is the smallest Johnson counter that covers at least 12 states?

A Johnson counter's cycle length is 2n for n flip-flops (linear, not exponential, unlike a binary counter's 2^n). To get exactly 12 states you would need n=6 flip-flops (2 x 6 = 12), which works out exactly. If instead the requirement were, say, 13 states, no exact n would work (2n is always even), so you'd need the smallest n giving at least 13 states, which is n=7 (2x7=14 states), and then add extra logic to skip the 2 unneeded states, similar to how a decade counter skips 6 unused binary states.

Recall a Johnson counter with n flip-flops produces exactly 2n states in its cycle, not 2^n — this is a linear relationship, not exponential.