The last log made me realise that there are some more errors to catch with relatively little effort. Not that PEAC couldn't catch this soon after but the "flaw" in question is that the parities of each byte are XORed and could cancel each other.

Since the markers have 3 values, this is a missed opportunity, but it still can't be perfect because 2 parities make 4 combinations, and one of them must be degenerate. But it's still better.

It is not possible to simply XOR the 2 marker bits with respective parities because a valid data word would turn into a control packet, and control packets have their own format to help with droop and such. Control markers REQUIRE a marker 11 to discern the start of a packet.

Converting 2 bits down to 3 codes can be done with a half-adder but this uses the slow XOR gate. AND and OR provide the same code compression (more or less) with shorter delay, such that we get :

pp    AO
00 => 00
01 => 01
10 => 01
11 => 11

Turning 01 to 10 would require one bit change on both bytes (Hamming distance of 2), simultaneously, so the strength is equivalent to the half adder.

This turns the parity into a 4×2 LUT

mm pp 
00 00 => 00
01 00 => 01
10 00 => 10
11 00 => ??
00 01 => 01
01 01 => 10
10 01 => 00
11 01 => ??
00 10 => 01
01 10 => 10
10 10 => 00
11 10 => ??
00 11 => 10
01 11 => 01
10 11 => 00
11 11 => ??

Some parts could look a bit like addition mod3.

We also already know that one way to reduce the LUT is to swap the inputs (or the outputs), that's a pair of MUX: it would be controlled by the AND of the parities. The OR just triggers the rotation.

By the way, there are 6 permutations of 3 elements:

 original  : 00  01  10   012
 left rot. : 01  10  00   120
right rot. : 10  00  01   201
alt1       : 00  10  01   021
alt2       : 01  00  10   102
alt3       : 10  01  00   210

But only 3 permutations (the respective rotations) ensure that all the elements are different for each position.

Then there is the old question from log 18: should we Protect the flip bits ?

Each flip bit controls logic that creates a Hamming distance of 8 so if the flip bit is altered, there is a strong chance to detect it with PEAC, so bring it on! Further altering the markers might not increase the error detection. This is important because the extra XORs add significant delays and the parities can cancel each other. Should the Hamming distance be maximised, or the alterations detected ASAP?

There are 4 levels of error detection:

• Byte's popcount below 4 (indepedent from the respective flip bit) => detected at the parpop stage
• Marker mismatch : detected 1-3 cycles after the error if data alteration, 0 cycle if parity altered
• Invalid checksum : at end of packet (but "leaks" during the whole sequence)
• Markers that encode a control word instead of data: this counts as a missing word in the sequence, which also affects the checksum

So every stage complement the others and contributes to the strong and early detection. Protecting the flip bits might not be critical after all: it only delays the detection by a few cycles at worst. So the new "marker rotation" could just skip the xor between parity and flip.

The whole pipeline must be tested, not just the individual parpop stage.

_______________

So here is the result :

and you can play with circuitjs. The VHDL should be updated and I'll compare the different versions.