The Ethernet PHY We Knew, The UALink PHY We Needed

Same building blocks. Same lane rates. So why not just use Ethernet PHY unchanged? 

The Myth We All Quietly Believe 

If you place an Ethernet PHY and a UALink PHY side by side, the first thing you notice is not how different they are. It is how similar they look. If UALink already uses Ethernet PHY technology, why does it need a separate physical layer at all? Why not simply use the Ethernet PHY unchanged? 

It is a reasonable question. UALink did not need Ethernet to become faster. Ethernet already had the speed. It did not need a completely new PMD, a new Reed-Solomon code, or a new way to train the link. What changed was something less obvious: the rule the PHY had to obey. 

Follow One Flit, and the Difference Appears 

Instead of walking through PCS, FEC, PMA, and PMD one block at a time, let us follow something the accelerator actually cares about: a 640-byte DL flit.

At the data link layer, that flit is one meaningful unit. The PHY has to protect it, move it across the link, recover it at the receiver, and hand it back without losing where that flit begins or ends. And here, UALink makes the decision that changes the rest of the story. 

Ethernet does not require packet boundaries to line up with FEC-codeword boundaries. A packet could begin in one codeword and end in another, and the PHY would not care. UALink deliberately creates a fixed relationship between a 640-byte DL flit and a single RS(544,514) codeword. Once that rule exists, anything that inserts, removes, delays, or rearranges data has to respect the flit boundary. 

The arithmetic explains why this relationship works. A 640-byte DL flit contains 5120 payload bits. After 64B/66B encoding and 256B/257B transcoding, the information expands to exactly 514 ten-bit Reed-Solomon symbols. Adding 30 parity symbols produces a 544-symbol RS(544,514) codeword. Now our flit has armor. But keeping that armor wrapped around exactly one flit creates the first problem. 

The First Thing Ethernet Already Solved — Until It Didn't 

Ethernet already knows how to align lanes. Alignment markers help the receiver identify lanes, remove skew, and restore the correct lane order. So why would UALink touch something that already works? 

Because Ethernet inserts alignment markers into the PCS data stream without caring about packet boundaries. UALink cannot do that. If an alignment marker were inserted using the traditional Ethernet mechanism, the carefully maintained DL-Flit-to-codeword relationship would be disturbed. 

To solve this, UALink introduces a coordinated RS and PCS mechanism. 

• RS generates a 'Start Flit Code Sequence' 

• PCS recognizes that sequence

• PCS overwrites specific 257-bit blocks with Ethernet alignment markers

• On receive, PCS reconstructs the marker-containing interval as an AM flit code sequence 

• RS uses that sequence to recover DL flit phase

The alignment markers on the wire are unchanged from Ethernet. What changes is the mechanism used to introduce and recover them. Same Ethernet alignment markers. Different handling around the flit. UALink did not reinvent the marker. It changed how the PHY makes room for it. 

The special start sequence also has to remain recognizable before the PCS replaces part of it with alignment markers. That is why the relevant leading blocks bypass scrambling: 

• 100G: first 20 × 64B/66B blocks 

• 200G: first 4 × 256B/257B blocks 

• 400G: first 8 × 256B/257B blocks 

• 800G: first 8 × 256B/257B blocks per flow 

The receiver performs the corresponding descrambler bypass and then resumes with the correct state.

Coming Back Is Harder 

Transmit knows exactly where every flit begins. The receiver does not. The receiver sees lanes arriving with possible skew, encoded codewords, alignment markers, and a continuous stream of blocks. Ethernet alignment markers already answer: Which lane is this, and how should the lanes be lined up? 

UALink needs one additional answer: Where does the next 640-byte DL flit begin? After the PCS establishes alignment, the marker-containing interval is reconstructed as an AM Flit Code Sequence. The RS recognizes it and establishes the nominal flit phase. From there, the receiver can count the stream in groups of 80 blocks, which is equivalent to one DL flit opportunity.

Then Latency Enters the Story 

Our flit is protected. It is aligned. But there is another question: How long does it have to wait? The answer involves FEC interleaving. 

Interleaving spreads adjacent symbols across multiple codewords so burst errors become easier to correct. The tradeoff is additional latency because codewords become dependent on one another.

Figure: Standard Ethernet combines PCS symbol distribution with an additional PMA delay to produce 4-way interleaving.

UALink's reduced modes remove the PMA delay and, for 1-way mode, also remove PCS pre-FEC distribution. In the reduced 2-way paths, UALink removes the additional PMA two-codeword delay. 

The tradeoff is intentional. 
Less interleaving → lower latency. 
More interleaving → better burst-error spreading. 

Ethernet's choice was not wrong. UALink simply needed another choice. 

The Problem Ethernet Gets for Free 

Ethernet packets naturally leave gaps. Those gaps provide Idle blocks, giving the PHY convenient places to absorb small clock differences. UALink's normal data path can instead look like this: 

Where does rate matching happen if there are no natural gaps? UALink solves this by creating its own opportunities. The RS periodically inserts an idle flit code sequence. UALink solves this by creating its own opportunities. The RS periodically inserts an idle flit code sequence. 

In the applicable operating states, the RS provides an idle flit code sequence for every 1,024 codewords, unless that position is being used for an alignment-marker opportunity. Rate matching can then add or remove Idle blocks at safe locations.

Back-to-Back Does Not Mean Boundary-Free

A normal UALink data flit already occupies one complete 80-block unit. So, another flit can immediately follow it. 

No new Ethernet start delimiter. No terminate delimiter. No mandatory inter-frame gap. Control sequences occupy complete flit opportunities only when the PHY needs them for alignment-marker handling, rate matching, Idle behavior, or fault signaling. 

What UALink Refused to Reinvent 

After seeing all these changes, it is easy to think UALink created a completely new PHY. It did not. UALink kept the parts the Ethernet had already solved well.

Inner FEC is conditional. It should only be shown where the selected IEEE PHY actually uses it; it is not a universal UALink KR/CR payload-path stage. 

One Last Thing 

We started with a myth: If UALink uses the same sublayers and the same speeds as Ethernet, why not simply use Ethernet PHY unchanged? Now the answer is clearer. The same building blocks do not mean the same behavior. Ethernet already had speed. 

It already had PAM4, RS-FEC, alignment markers, lane recovery, auto-negotiation, and link training. UALink did not need to reinvent those things. What it needed was for those familiar mechanisms to obey a different rule: Keep the flit together. Once one 640-byte DL flit became associated with one protected FEC codeword, everything around that relationship had to cooperate.

Alignment marker handling changed. Receive synchronization gained a flit boundary. Reduced-interleave options appeared. Rate matching moved to safe opportunities. Back-to-back traffic followed a fixed 80-block rhythm. Not because Ethernet failed. Because Ethernet was solving a different problem, and the Ethernet PHY we knew already knew how to move bits fast. The UALink PHY we needed taught those same building blocks how to move flits predictably. 

Testing this carefully coordinated PHY behavior requires more than checking that bits move across the link. Verification must prove that the DL-flit-to-FEC-codeword relationship is preserved, alignment-marker opportunities are handled without breaking flit phase, receive logic can recover the correct 640-byte boundary, reduced-interleave modes behave as intended, and rate matching occurs only at safe Idle Flit Code Sequence locations.

Cadence UALink VIP helps verification teams validate this end-to-end behavior with flit-aware and protocol-aware visibility across the stack, from UPLI down to PHY. Teams can drive realistic traffic, monitor flit/codeword alignment, exercise marker and idle-sequence scenarios, inject malformed conditions, and validate recovery behavior—turning UALink PHY architecture into measurable proof of design robustness. To integrate this validation capability into your environment, contact Cadence Support, visit the Simulation VIP for UALink product page, or explore the wider range of Cadence Simulation VIP solutions. For any clarification or technical assistance, please reach out to us at talk_to_vip_expert@cadence.com.