Ripple counter worst-case delay with unequal tPHL/tPLH Four flip-flops form a ripple counter. Each has tPHL = 22 ns and tPLH = 15 ns. What is the maximum total delay that can occur through the chain?

Introduction / Context:
In ripple (asynchronous) counters, each stage is clocked by the previous stage’s output, so propagation delays accumulate. When rise and fall delays differ (tPLH vs tPHL), the worst-case total chain delay uses the larger per-stage delay because any transition may propagate through the polarity that is slowest at each step. Estimating this upper bound is key to deciding maximum safe clock rates and decode timing windows.

Given Data / Assumptions:

• Four cascaded flip-flops (4-bit ripple counter).
• Per-stage delays: tPHL = 22 ns, tPLH = 15 ns.
• Worst-case chain delay sought.

Concept / Approach:

The total worst-case ripple time ≈ number_of_stages * max(tPHL, tPLH). That ensures coverage regardless of edge polarities encountered along the chain. For this device, tPHL dominates at 22 ns.

Step-by-Step Solution:

Verification / Alternative check:

Timing diagrams for transitions like 1111→0000 illustrate sequential toggling with per-stage worst-case delays accumulating to roughly 88 ns before all bits settle.

Why Other Options Are Wrong:

15 ns, 22 ns: single-stage delays, not the full chain.

60 ns: assumes 4 * 15 ns; ignores the slower direction tPHL.

Common Pitfalls:

Using average delay or the faster edge; ignoring that decode logic must wait for the MSB to settle to avoid glitches.

Final Answer:

88 ns