I realise that I was wrong about how errors behave with PEAC, mostly because even after 4 years I was still caught in the LFSR/checksum framework/mindset.

Let's start with the test of naked PEAC in test/test_PEAC.vhdl where one data bit is toggled during cycle 7:

5 (so far, normal)
coder:  C=0 D=0 X=0110010101011101 o/Y=0100110100011000  - MsgIn=0000000000000000
decod:  C=0 D=0 X=0110010101011101   Y=0100110100011000      Msg=0000000000000000
6
coder:  C=0 D=0 X=1011001001110101 o/Y=0110010101011101  - MsgIn=0000000000000000
decod:  C=0 D=0 X=1011001001110101   Y=0110011101011101      Msg=0000001000000000
7
test/test_PEAC.vhdl:109:7:@0ms:(assertion error): Data Mismatch  (but the receiver doesn't know it yet)
coder:  C=1 D=0 X=0001011111010010 o/Y=1011001001110101  - MsgIn=0000000000000000
decod:  C=1 D=0 X=0001100111010010   Y=1011001001110101      Msg=0000000000000000 nothing here yet
8
coder:  C=0 D=0 X=1100101001001000 o/Y=0001011111010010  - MsgIn=0000000000000000
decod:  C=0 D=1 X=1100110001001000   Y=0001011111010010      Msg=1111111000000000  (something strange here)
9
test/test_PEAC.vhdl:109:7:@0ms:(assertion error): Data Mismatch
test/test_PEAC.vhdl:113:7:@0ms:(assertion error): Carry Mismatch Now it complains !

coder:  C=0 D=0 X=1110001000011010 o/Y=1100101001001000  - MsgIn=0000000000000000
decod:  C=0 D=1 X=1110010000011010   Y=1100101001001000      Msg=1111110111111111 Now that's something weird !
10
test/test_PEAC.vhdl:109:7:@0ms:(assertion error): Data Mismatch
test/test_PEAC.vhdl:113:7:@0ms:(assertion error): Carry Mismatch  And the complaint will stay

The error immediately bubbles up to the MSB and sets the carry flag, and then it somehow looks like it bubbles down. This effects appears for any position of the set bit : in 2 cycles the error is caught by the carry flag.

This is suspicious because the input word is cleared so it must have an effect, somehow. Hypothesis confirmed by using a constant message with value "0100 0000 0000 0000": the carry does not propagate, blocked by the set bit.

5
coder:  C=1 D=1 X=0010010101011110 o/Y=0000110100011001  - MsgIn=0100000000000000
decod:  C=1 D=1 X=0010010101011110   Y=0000110100011001      Msg=0100000000000000       
6
coder:  C=0 D=0 X=0011001001111000 o/Y=0110010101011111  - MsgIn=0100000000000000
decod:  C=0 D=0 X=0011001001111000   Y=0110011101011111      Msg=0100001000000000       
7
test/test_PEAC.vhdl:110:7:@0ms:(assertion error): Data Mismatch
coder:  C=0 D=0 X=1001011111010111 o/Y=0111001001111000  - MsgIn=0100000000000000
decod:  C=0 D=0 X=1001100111010111   Y=0111001001111000      Msg=0100000000000000       
8
coder:  C=1 D=0 X=0000101001001111 o/Y=1101011111010111  - MsgIn=0100000000000000
decod:  C=1 D=0 X=0000110001001111   Y=1101011111010111      Msg=0011111000000000       
9
test/test_PEAC.vhdl:110:7:@0ms:(assertion error): Data Mismatch
coder:  C=0 D=0 X=1110001000100111 o/Y=0100101001001111  - MsgIn=0100000000000000
decod:  C=0 D=0 X=1110010000100111   Y=0100101001001111      Msg=0011111000000000       

No carry mismatch now. Something must force the carry to propagate further and affect the carry.

Another test shows the importance of the data pattern;

6
coder:  C=0 D=0 X=1011001001110011 o/Y=0110010101011011  - MsgIn=0101010101010101
decod:  C=0 D=0 X=1011001001110011   Y=0110011101011011      Msg=0101011101010101       
7
test/test_PEAC.vhdl:110:7:@0ms:(assertion error): Data Mismatch
coder:  C=1 D=1 X=0001011111001110 o/Y=0000011111001000  - MsgIn=0101010101010101
decod:  C=1 D=1 X=0001100111001110   Y=0000011111001000      Msg=0101010101010101       
8
coder:  C=0 D=0 X=0001111110010111 o/Y=0110110100100100  - MsgIn=0101010101010101
decod:  C=0 D=0 X=0010000110010111   Y=0110110100100100      Msg=0101001101010101       
9
test/test_PEAC.vhdl:110:7:@0ms:(assertion error): Data Mismatch
coder:  C=0 D=0 X=1000110010111011 o/Y=0111010011101100  - MsgIn=0101010101010101
decod:  C=0 D=0 X=1000111010111011   Y=0111010011101100      Msg=0101001101010101       
10
test/test_PEAC.vhdl:110:7:@0ms:(assertion error): Data Mismatch

And the alteration does not move if the input data remains identical.

To force this situation to affect the carry, a first tool is the GrayPar circuit that cascades the alterations up to the 6 MSB (for single-bit errors). But then it stays there. At least now the range of errors is confined.

The second tool is a "generalised PEAC" (gPEAC), that is : a modulo that is not a power of two. From the above description, we know that the MSB of the modulus must have 6 consecutive 0s, since when transformed (subtraction turned to addition) the modulus is complemented and we need at least 6 bits that are set to propagate the error.

The current PEAC holds flipped bits in their position so it is better for error correction, but the protocol would have to wait until the end of the packet to find it out, by checking the checksum field. OTOH this projects insists on early detection, hence avalanche.

There is still the question of the buffer depth: how many words should be required at worst ?
One the one hand, this PEAC has 34 bits of state and each word has 2 carry bits so 34/2=17 words. In fact, an error is not characterised by changing the carry bit since any other data can affect it, but it matters when. And it takes about 25 iterations for the LSB of the Fibonacci to turn into a value larger than 64K. So the more carry bits are checked, the more certain we are of the integrity. This is why the GrayPar is so important for amplifying errors.

17 or 25 words is too deep for practical uses, this would only detect errors during the data bursts. Control words need to be short so they can spend 25 cycles in quarantine. It's not possible to dump the checksum registers either but there is one possibility though:

Any error will leave a trace, an offset, on every word after 2 cycles, so the protocol can dictate that every control word be followed by a NOP 2 cycles later. If the control word is affected, the NOP will be altered too and this keeps the quarantine short.

So there are two modes of operation :

• Control words are always followed by a NOP (or two if nothing else is available for interleaving)
• Data bursts rely on carries and checksums for detection.

Actually, a checksum is not required "per se" ! Just send 2 NOP at the end of the packet and you're done. This saves an EOP word in the vocabulary !