@SHAOS will love this log !

PAM3 has several compelling sides, where to start ?

PAM3 is pretty similar to MLT3 on the analog side. The A/D interface requires only a pair of differential input pins, as already examined in 3. AGC and same same for the output drivers. So it's the same cost and AFE as MLT3, while PAM4 goes to another level (and needs at least 3 diff input pins).

PAM4 is more sensitive to line distortions/alterations/etc, since the intersymbol distance is closer. PAM4 makes it easy to map bits to line states but the AFE is less robust/simple/cheap. I'm looking for something... "rustic".

NRZi is all fun & games but it brought us quite a lot of complications with the RLL part, which has led to the creation of the ParPop unit. It works but the coding density is far from optimal, it requires MLT3 to shine.

PAM3 is not a power of two, so there is quite some matching to do. Usually trits are bundled to build a larger symbol space with, if possible, few leftovers that get assigned to control codes.

t    3^t    bin  bits  rem
1      3      2   1      1
2      9      8   3      1  <= 3B/2T code
3     27     16   4     11
4     81     64   6     17
5    243    128   7    115  ah, so close to 256...
6    729    512   9    217
7   2187   2048  11    139  <= 11B/7T code  
8   6561   4096  12   2468
9  19683  16384  14   3299
.....

With larger trit blocks, it becomes possible to play other games such as disparity corrections and error correction, but the size of the circuit explodes. That's not rustic, and who can easily align word to 11-bit boundaries ?

So the 3B/2T code looks the most interesting, as it is a direct divisor of 18 (the word width) and as mentioned earlier in 42. The "same" symbol, the only extra leftover code (0,0) is interesting to reduce activity/power/EMI/Droop.

The actual mapping from 8 codes to 2 trits is to be determined later. It will depend on the MSB's value, since it marks the start of a word. There is one important constraint though: the mark's symbol (11x)b must not be encoded in a trit that starts with (0,x)t or else the frame is shifted and invalid.

Some scribbling later, playing with Hamming distances, and I get this code:

bits  trits
 000   + 0
 001   - 0
 010   0 +
 011   + +
 100   - -
 101   0 -
 110   + -
 111   - +

  S    0 0

Reverse table:
trits  bits
 - -   100
 - 0   001
 - +   111
 0 -   101
 0 0    S
 0 +   010
 + -   110
 + 0   000
 + +   011

The table looks pretty different from the others, to avalanche bit errors, and it is characterised by a central symmetry, if looked as a graph. I managed to get H2 and H3 for neighbour symbols, except for 2 cases.

And the "Same" symbol is there to reduce redundancies.

Another interesting property is that the all-1s word 111 111 111 111 111 111 is encoded as -+-+-+-+-+-+ which gives clear signals to help resync.

One thing is lost, compared to MLT-3 : the differential NRZi is polarity-independent so you can swap the pair's wire at will. The symmetry of the symbol table helps with adjusting to the signal polarity, with just a few XOR here and there:

XOR LSB:
000 → +0 // -0 → 001
110 → +- // -+ → 111

XOR all:
010 → 0+ // 0- → 101
011 → ++ // -- → 100

The polarity could be auto-detected during the "sync burst" since it starts with -.

The sync word should also help with the order of the pairs: 111 111 111 111 111 111 is split into 111 111 111 and 111 111 111 then encoded as -+-+-+ on both lanes so it's impossible to know which is which. One half should receive a slightly different word when in dual-lane configuration, ending with a different pattern such as -+-+-0

==> the last trit of a sync word must be left available for auto-detection.

And since 2 lanes makes sync shorter and harder, 2 words are required instead of one to keep enough temporal margin (so the DPLL can adjust the phase well enough).

• -+-+-+ for single-lane
• -+-+-0 for lane 0
• -+-+-- for lane 1

Another drawback: going from MLT3 to PAM3 makes transitions + to - and - to + possible, which triggers both phase samplers at roughly the same time. We'll see if/how this becomes a problem and how to mitigate it.

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

The control words "start of packet" and "end of packets" all contain a 2-bit field and a 11-bit field:

• 2 bits for the buffer/transaction number of start-of-packet, and the offset of the checksum word
• 11 bits for the packet size (2048 words) and a slice of the checksum

OK this pushes the buffer sizes to 4Ki bytes but using 3 dedicated "end of packet" words that contain one third of the checksum helps with not mixing the data with the checksum, so the data size is not limited to 2046 words/4092 bytes.

We get :

• 110 10b bss sss sss sss for "start of packet bb of size sssssssssss" (off-by-one)
• 110 11n ncc ccc ccc ccc for "checksum slice #nn = ccccccccccc" (n=00 01 10)

and yes it's tempting to fold bb and nn, which would save one bit, so there would be only one buffer in flight at a time. Buffer management would require more/other control words.

The first trit would indicate the type of message:

• 110 is the sender info (start/end/keepalive)
• 111 is feedback / status (sync, OK+crc, retry+index, timeout...)

...

110 110 110 110 110 xxx signals "change parity" (it collides with checksum slice above)