What an LDPC bit-flipping decoder actually spends its energy on

A bit-flipping decoder looks embarrassingly cheap on paper. Flip the least reliable bits, recompute the affected checks, repeat. In practice it is a memory system with a small amount of arithmetic attached, and the arithmetic is not where the time goes.

The loop is the bottleneck

Each iteration reads check-node messages, flips a subset of the variable nodes, and writes results back. The amount of arithmetic per bit is trivial. The amount of data moved per bit is not.

// The naive version: every iteration reads the whole syndrome table.
for (int iter = 0; iter < MAX_ITER; iter++) {
    for (int cn = 0; cn < NUM_CN; cn++) {
        load_check_node(cn, syndrome);      // memory traffic dominates
        for (int i = 0; i < CN_DEGREE; i++) {
            if (fabs(syndrome[i]) > threshold) {
                flip(variable_node[cn->vars[i]]);
            }
        }
    }
}

Adding two-bit strength — flipping two bits per variable node instead of one — roughly halves the number of iterations needed. But the win only shows up if the architecture stops re-reading the same tables every round.

Convergence versus iterations

Turbo decoding was the actual algorithmic contribution. Taking the most confident bit from the previous iteration and feeding it forward removes the ambiguity that makes single-bit decoders stall:

TTGDBF:  two-bit gradient descent + turbo feedback
         convergence accelerated 75.6% over UP-GDBF
         FER < 1e-7 maintained at 0.003 RBER

The result that matters is not the 75.6% on its own. It is that the accuracy target did not move. Speeding up a decoder by throwing away iterations is not a result; speeding it up while holding the error rate is.

What the tapeout changed

The TSMC 65nm implementation came in at 0.992 mm² and 15.87 Gbps, with hardware complexity down 55.5% against the reference decoder. The architecture changes that mattered were unglamorous:

• Message buffers sized by the two-bit schedule, not by the worst case.
• Check-node reuse across the turbo feedback path, so a value computed for iteration n is available to iteration n+1 instead of being recomputed.
• Early termination on syndrome parity, which matters enormously for random-looking data where most codewords converge far below the iteration cap.

The lesson

If the bottleneck is a data movement problem, changing the substrate beats optimising the loop. That instinct — optical decoding, compute-in-memory, near-memory — is the thread running through everything I have worked on.