Why Faster Isn't Always Better: UALink Transmitter Pacing Explained

Imagine two accelerators connected through a UALink link operating at full bandwidth. The link is running at full line rate, DL flits are flowing across the wire, and transactions are moving between devices. Yet one of those accelerators may already be falling behind.

The reason is subtle. In UALink, the physical link and the accelerator behind it do not necessarily operate at the same rate. An accelerator may reduce its UPLI clock frequency for power-saving purposes while the link itself continues operating at line rate. This situation can occur when an accelerator is not fully utilized and chooses to lower its operating frequency to reduce power consumption, even though the UALink connection remains active. That creates an interesting engineering challenge: how do you prevent data from arriving faster than the receiver can consume it?

The answer is transmitter pacing.

The Journey from Transaction to Wire

Before discussing pacing, it helps to understand where it fits in the UALink stack.

A transaction begins at the functional/protocol layer, is packaged into 64-byte TL flits by the transaction layer, packed into 640-byte DL flits by the data link layer, and ultimately transmitted by the PHY across the serial link.

Figure 1: The UALink protocol stack 

Under normal conditions, data enters and exits the receive path at roughly the same rate. The interesting part begins when the receiver intentionally slows down.

When the Link Is Faster Than the Accelerator

UALink allows accelerators to operate their UPLI clock below the maximum rate to reduce power consumption. The physical link, however, does not automatically slow down.

The receive-side adaptation FIFO is written using a rate derived from the recovered link clock, while data is removed by the transaction layer running on the local UPLI clock. If that UPLI clock is reduced, data can arrive faster than it is consumed. FIFO occupancy grows over time, eventually creating an overflow risk.

Figure 2: Receive-side rate mismatch

This is the problem transmitter pacing was designed to solve.

What Transmitter Pacing Actually Does

A common misconception is that pacing slows the physical link. That is not what happens.

The serial link continues operating at line rate. DL flits continue being transmitted. What pacing controls is the rate at which TL flits are admitted into the DL transmit path. In other words, pacing acts between the transaction sayer and the data link layer, regulating how quickly useful traffic enters the link.

This distinction is important because the goal is not to throttle the wire. The goal is to prevent the receiver from becoming overloaded when it is operating at a lower UPLI frequency.

The Challenge Hidden Behind a Simple Requirement

So far the solution sounds straightforward:

• Notify link partners about rate changes
• Adjust pacing
• Prevent receive-side overflow

What the specification does not fully define is how pacing should be implemented. That creates an interesting design challenge.

Consider a simple example. A transmitter is operating at full UPLI rate. Its link partner is operating at half that rate. Now, assume the link remains idle for a period of time. No TL flits are being admitted, and no useful traffic is sent. When traffic suddenly arrives, a natural question appears: Can the transmitter take advantage of that earlier idle period and temporarily send data more aggressively?

From a utilization perspective, that sounds attractive. After all, no traffic was sent during the idle interval. But from the receiver's perspective, sending a large burst immediately afterward may create much higher instantaneous FIFO occupancy. This is where implementation choices begin to matter.

Should pacing strictly match the advertised long-term rate? Should some accumulation of unused opportunities be allowed? If so, how much? The specification intentionally leaves these implementation decisions open while still requiring that receive-side overflow never occurs. That turns pacing from a protocol feature into an engineering problem.

Why Verification Gets Interesting

Many protocol features can be validated with straightforward directed tests. Transmitter pacing is different. A simple test may show:

• TL rate notifications were exchanged
• ACKs were returned
• Traffic continued flowing

Everything appears correct. The difficult cases emerge over time. Questions quickly arise:

• Was the new rate applied when expected?
• Was the receiver protected under sustained traffic?
• Did idle periods affect behavior correctly?
• What happens when both ends of the link change rates independently?

These are not packet-level questions. They are behavioral questions that play out over thousands of cycles. That is what makes pacing a particularly interesting verification problem.

The Takeaway

UALink transmitter pacing exists because the physical link and the accelerator behind it are not always operating at the same rate. The specification allows accelerators to lower their UPLI clock frequency for power reduction while the UALink link continues operating at full speed. Without pacing, the receive-side adaptation FIFO could fill faster than it is drained, eventually leading to overflow.

What makes the feature especially interesting is that the specification defines the goal but largely leaves the implementation strategy to the designer. The protocol tells us what must be achieved. The details of how it is achieved are implementation-specific. For verification teams, that turns pacing from a simple protocol mechanism into a system-level behavior that must be validated across changing rates, idle periods, and real traffic scenarios. 

Cadence UALink VIP is designed to help verify exactly these situations. By providing visibility across UPLI, TL, DL, and PHY, it enables engineers to observe the impact of rate changes throughout the protocol stack. Protocol-aware checkers continuously monitor rate notifications, pacing-related behavior, and receiver-protection requirements, while detailed logs provide visibility into how the design responds to changing operating rates. Together, these capabilities help engineers validate pacing behavior and receiver protection while ensuring compliance with UALink protocol requirements.

For further details, contact Cadence support or visit the Simulation VIP for UALink product page. You can also explore Cadence Simulation VIP solutions for broader protocol VIP support.

The result is a simple but powerful lesson: in UALink, maximum performance is not achieved by sending data as fast as possible. It is achieved by matching transmission behavior to the rate the receiver can sustainably consume, even when the link itself continues operating at full speed.