Ripple carry adders chain full adders with carry propagation through all stages. Simple to implement but slow—each bit must wait for the carry from the previous stage, limiting performance.
From your work with full adders, you know that a single full adder takes three 1-bit inputs — two data bits (A and B) and a carry-in (Cin) — and produces a 1-bit sum and a carry-out (Cout). A ripple carry adder extends this to multi-bit addition by chaining N full adders together, one per bit position. The carry-out of each full adder connects to the carry-in of the next higher bit's full adder. For a 4-bit adder adding A[3:0] and B[3:0], you wire four full adders in sequence: the first handles bit 0 (with Cin tied to 0 for simple addition), its Cout feeds the Cin of the bit-1 adder, and so on up to bit 3.
The design is beautifully simple — it is literally just N copies of the same building block connected in a chain. Each full adder computes the correct sum for its bit position *provided it has the correct carry-in*. And that is exactly the problem: the bit-1 adder cannot produce its final output until bit 0's carry-out is available. Bit 2 waits for bit 1, bit 3 waits for bit 2, and so on. The carry signal ripples through the chain like a wave, and the final result is not valid until the carry has propagated through every stage. This gives the circuit its name.
The performance consequence is direct. If each full adder has a gate delay of *d* for generating its carry-out, then an N-bit ripple carry adder has a worst-case delay of N × *d*. For a 32-bit adder, that is 32 propagation delays before the most significant bit's sum is correct. In a processor running at gigahertz clock speeds, where a clock cycle might allow only a handful of gate delays, this sequential propagation becomes a serious bottleneck. The worst case occurs when a carry propagates through every bit — for example, adding 1 to 01111111 produces 10000000, requiring the carry to ripple from bit 0 all the way to bit 7.
Despite this speed limitation, the ripple carry adder matters because it establishes the baseline: it uses the minimum number of gates (each full adder needs about 5 gates), has the simplest wiring, and is the easiest to verify. Every faster adder design — carry-lookahead, carry-select, carry-skip — exists specifically to break the sequential carry chain that defines the ripple carry adder. Understanding *why* the ripple carry adder is slow is the prerequisite for understanding *how* those optimized designs achieve their speedups by computing carries in parallel rather than in series.
No topics depend on this one yet.