Log 44. The ParRot has shown some limits and constraints of working in ternary. I must revise my approach and find a better compromise. So I have split the unit in two parts

• The "spreader" (this log)
• The "ternarity" (tbd)

The new "spreader" circuit has a few purposes:

• as the name implies, it "spreads" the bits, as in the "diffusion" in "confusion-diffusion" (in that vein, confusion would be the PEAC stage).
  • it mixes the bits with far neighbours to de-localize errors, outside of a single bi-trit's reach (more than 4 bits)
  • it increases the mixing so errors avalanche faster in the PEAC stage => reduce the retransmit buffer size.
• the same circuit and gates are shared for encoding and decoding, mixing and de-mixing. The process looks like Gray coding/decoding but that was not the intent, just a convergence of purposes/needs.
• The spreader is architectured to also optimise for easier signature and help compute ternarity.

The 16 bits are partitioned in 4 groups of 4 bits. They get independently mixed and the groups are interleaved. Each group also generates one non-local parity bit, then the 4 parities get encoded in ternary (the annoying part).

For the first group, value #0 is directly encoded, then xored with #8, so distance=8. Then xored with #4 (distance=4) then #12 (distance=12). The other groups are identical with a shift of 1 each.

b0 = a0
b1 = a0 ^ a8
b2 = a8 ^ a4
b3 = a4 ^ a12

 In other words, this is the parallel Gray code, and the reciprocal/decoding is "serial" :

a0  = b0
a8  = b0 ^ b1
a4  = b1 ^ b2
a12 = b2 ^ b3

The 4 groups of 4 is a compromise to reduce the length of said chain of XOR.

If one bit is altered, 3 out of 4 times its value will also alter two other values.

And the formula is the same on the first 2 line so only 2 more XORs are chained, the same unit can both encode and decode (just add a mux and shake well).

Parity comes almost for free then :

b1 = a0 ^ a8
b3 = a4 ^ a12
p  = b1 ^ b3

Just one more XOR and it's done.

More or less because the indices are interleaved so either the circuit is duplicated, or MUXes are needed.

Here's a first try with CircuitJS:

The avalanche works quite well, all 1-bit errors always get detected and if the output bits are well-ordered, 1 to 4 bits get toggled due to the cascade of XORs.

Except for the combination of toggles on C0 and C1 (where only d0 is affected), the other error patterns of the group do affect all other output bits, so the bit 4 is guaranteed to be set, thus skipping several cycles during a retry.

Overall this accelerates the rate of error propagation in PEAC and window of the time for error detection (though the worst case still exists but it less probable).

The "end of the cascade" must be oriented toward the MSB so more errors can propagate faster toward the MSB of PEAC.

..........................

The parity part is quite surprising.

On the sender side, it's easy : "add a XOR".

On the receiver side, it's also "add a XOR" but on the very same two signals that get sent and probably altered too.

Can there be two parities on the receiver side ? One that is directly extracted from the Gray-encoded data, and another from the decoded word ? That would give an "early parity" and later a "full parity"...

..............................

More simulations have brought the necessary insight.

The trick here is that errors get detected only on the pins connected to the Qa XOR : C1 and C3. And only one can detect an error at a given moment.

Inserting errors on the other pins (C0, C2) does nothing to the error detection since the cascade will affect an even number of outputs (both d4 and d12 usually) thus preserving the overall parity ===> The parity must be computed from the output of the Gray-encoded word, or else only a few signals get "protected".