Most of the project's development is centered around the gPEAC scrambler, as a demonstration of its unusual qualities, but more has to be developed upstream and downstream, host-side and link-side.

There is this idea of using a classic MII floating around, but even the simplest 10/100 PHYs are particularly complex, in particular due to the requirement of a MDIO interface. So the idea could work but at a high design cost.

The next idea is to define a simplified interface/protocol, tailored for our needs. And the last log suggested some ways to do it. When translated to a physical protocol we get the 4-state system:

• Quiet : no activity, link down or pause
• Sync : establishing the link, synchronising and ensuring data integrity.
• Data : transmission in progress (can be data or control words, determined later in the descrambler)
• Error : something is wrong, please reset the link.

It takes only 2 bits, the FSM diagram is pretty simple and not very subtle: the states Q-S-D-E occur in sequence (though E can be skipped during normal operation).

And it works both ways: on the sender and the receiver side, it is bidirectional.

The protocol is source-clocked (Clk), with the 2 state bits QS and DE. Here I have shown 3 data bits but it's not a requirement, and maybe a "data enable" bit could also be useful but it means nothing outside of the D state.

Bubbles could be inserted in the D state, by setting the Data to a certain value and setting the Quiet state, I'll see, or maybe a "keepalive" state ? Or maybe "keepalive" is just NOPs for now.

This simplified MAC-PHY interface can work on-chip or off-chip. And for dual-lane configurations, a second PHY is used: the scrambler must manage the alignment and splitting of the words into correct-sized nibble.

So I can develop the scrambler and PHY independently now. Is it worth it to split the project to develop the PHY separately ?