With the almost-completed PEAC+GrayPar layers, the transmitted format is now settled: that will be 20 bits per word.

Then the word can be sliced and diced in several ways, depending on the speed, number of available lanes and the phase of the moon...

• 1 bit per cycle: the classic serial/NRZ scheme. 20 clock cycles.
• 2 bits per cycle: like the above with 2 lanes, or PAM4, or DDR NRZ. 10 cycles.
• 3 bits nibbles: Bi-PAM3, 7 nibbles + 1 "start" bit ?
• 4-bit nibbles: for use with a standard PHY ? that would make 5 nibbles, but they must come in pairs so that would be 2 words or 40 bits.
  or 2-lane PAM4 or 2-lane NRZ-DDR.
• 5 bits per nibble: 4 cycles per word, but no idea how that would be transmitted...
• 7 bits per byte ? The 8th bit would be added for transition minimisation (see ParPop). 3 cycles per word... but line coding is a mess again.

If 2 lanes are possible, then a clocked NRZ scheme is possible, possibly using DDR. This would provide 10 to 30Mbps without too many PLL issues and to prevent droop, the clock can be switched from a lane to the other after each nibble. Weird but possible.

At first (and enable practical prototyping) the basic constraint is to use a standard A3P250 and use its differential DDR IO as multi-level comparators, over 1 or 2 lanes, in PAM3. This makes the bi-PAM3 (or even quad-PAM3 for 2 lanes) possible but the 7 nibbles waste one bit (could be used for reframing).

To speed the design up (and cut the hassles of analog front ends), a "classic" 100Base-TX PHY could be used over its MII but I don't what to have to deal with the damned MDIO sidechannel: that's too much to handle, too much SW to write and maintain... so i'd need a PHY with easy configuration through IO pins for example. Plug&play as they said...