The first thing I draw for a new decoder is still not a block diagram. It is the iteration schedule: what is computed, in what order, and how many times.
Why the block diagram lies
A block diagram asserts that the modules exist and the boundaries are fixed. Both are usually premature. In the LDPC work the natural first cut was "bit-flipping engine, then syndrome checker" — and the interesting result came precisely from interleaving those two so that a value computed in one is available in the other.
The order that works
- Write the algorithm as pseudocode with explicit iteration counts. No parallelism yet.
- Establish the accuracy target numerically. Simulate until FER is comfortably below specification. If it is not, the architecture question is premature — a faster machine running a worse algorithm is still wrong.
- Then decide what can run in parallel, and what is genuinely sequential.
- Only then draw the block diagram, because at that point it is a summary rather than a guess.
The cost of getting it backwards
Reversing steps 1 and 2 is how designs end up with a beautiful parallel architecture that misses the error-rate target by an order of magnitude, and then get respun twice. Simulation is cheap. Silicon is not.
On tooling
`.``bash
The loop that actually matters, run before any RTL is written.vcs -full64 -sverilog tb/decoder_tb.sv # functional verdi -ssf waves.fsdb # debug
Everything in that loop runs in minutes. The place where it is tempting to skip
ahead is exactly the place where it pays to stay a week longer.
- asic
- design-methodology
- rtl