CRC/Parity/Hamming Protect 16-bit parallel bus
If your bit-error rate is measurable but not so high that no level of error-correction logic would help, you should either slow down your communications rate by 1% or so, or use the "best" 16 bits of your bus and not bother with the others.

Error correction logic is only useful in cases where the probability of an errors is relatively low and the probability of two errors occurring is far below the probability of one, the probability of three errors occurring is far below that, etc.  For a connection between a CPU and an FPGA, either you'll be meeting timing constraints, in which the most probable causes of errors will be things like power-supply glitches (which should be best addressed by power-supply improvements), you'll significantly miss timing constraints (in which case at least some bits of the bus will routinely yield incorrect data), or you'll be right on the edge of meeting timing constraints (in which case increasing timing margins even a little may help enormously).

If you were worried about guarding a parallel-data cable that went between boards, then the primary data to be guarded against would probably be that of a disrupted communication (e.g. one that was happening while a connector was unplugged) being perceived as legitimate.  Unless very-short-turnaround transactions are required (as might be the case here), such things are best guarded against by performing a CRC or other validation code on all the words of a longer transmission.  Appending a two-word (32-bit) CRC to a 64-word transmission would less overhead than adding a parity bit to each word, but would be far more likely to detect transmission errors.