Synopsys
Ansys

Finding the Right Balance of UCIe Bandwidth, Power, and Latency

Manuel Mota

Oct 28, 2026 / 4 min read

Subscribe to Our Blog
Thanks for subscribing to the blog! You’ll receive your welcome email shortly.

Introduction

Die-to-die interfaces were designed to be slow and wide. Long-reach SerDes push a few lanes as fast as possible. A die-to-die link takes the opposite approach: it uses many lanes at a modest rate over a very short, well-behaved channel. That approach keeps the circuits simple and the energy per bit low.

For AI and HPC applications, die-to-die links today have to be fast and wide, and the UCIe specification has moved quickly to keep up. Data rates have climbed from 16 GT/s to 32 GT/s and now to 64 GT/s. With each step up in data rate, some of the simplifications that made these interfaces efficient stop holding.

For architects, the useful question is which data rate fits the workload, rather than how fast the PHY can go.

What changes as data rate goes up

Three problems get worse as you raise the per-lane rate.

The channel gets harder. A higher Nyquist frequency means more loss through the package, so the received signal gets weaker. Crosstalk between densely packed bumps or microbumps also becomes a bigger problem than it was at lower rates. The PHY compensates with stronger drivers and more equalization, and both cost power.

Serialization goes up. The on-die system bus runs at a fixed clock that the die-to-die link doesn't control. A faster lane rate means more serialization and deserialization between that bus and the PHY. More serialization costs power and, more importantly, adds latency. Latency is often the parameter a die-to-die designer can least afford to give up.

The architecture changes. Going past roughly 32–40 GT/s eventually forces a next-generation PHY architecture, with its own area, power, and maturity costs.

That's why some customers run their links as slowly as their bandwidth target allows, so they can cut power and latency or simplify the protocol layer. The right data rate depends on the application.

Why 40G

Many designs need more bandwidth than 32 GT/s provides but don't need, or can't afford, the overhead of a 64 GT/s implementation. That's the gap 40 GT/s (40G) fills.

When both sides of the link support it, 40G gives 25% more bandwidth per lane than 32 GT/s, using the same PHY architecture, tuned for the higher rate. You can use that bandwidth in two ways:

  • Less area and shoreline. For a fixed bandwidth target, you need fewer PHY modules. That frees die edge for other I/O or shrinks the die-to-die footprint.
  • Headroom for traffic. You keep the same PHY count and get extra margin for bursty or growing workloads, without redesigning the link.

You get this without the power and area of a 64G-class design. At 40G, the PHY can handle the channel without the driver strength and equalization needed at higher rates.

40G is an optimized data rate beyond 32 GT/s. The UCIe specification names a generation by its highest data rate and requires support for every lower rate. Your link still interoperates at standard rates when the other side of the link doesn't support 40G.

Maturity and node coverage matter as much as speed

A multi-die design almost always spans more than one process node. Typically, the compute die goes on the most advanced node, and I/O, memory interface, or accelerator dies go on a node chosen for cost and analog behavior. The die-to-die IP has to be available, mature, and consistent on each of those nodes, or every chiplet carries its own integration risk.

Synopsys 40G UCIe IP meets that requirement. It is silicon-proven on 2-nm and 3-nm processes, a common pairing in advanced designs today, with 2-nm for compute and 3-nm for peripheral dies. Both the UCIe-S (standard package) and UCIe-A (advanced package) versions are proven at 40G, in Synopsys test chips and customer silicon.

The results

We look at two measurements first when validating a die-to-die PHY.

Eye opening across corners. A wide-open eye under realistic conditions shows real timing and voltage margin.

Diagram illustrating the UCIe-A N3P 3 nm cumulative 64-lane transmit and receive eye at 40 GT/s. Key elements include a white central opening, red and pink bands, purple outer regions, grid lines, and dashed reference lines.

40 GT/s TX+RX Eye on 3-nm

Diagram illustrating the UCIe-S N2P 2 nm cumulative 16-lane transmit and receive eye at 40 GT/s. Key elements include a white central opening, red and pink bands, purple outer regions, grid lines, and dashed reference lines.

40 GT/s TX+RX Eye on 2-nm

Bit error rate under load. We measure BER with many lanes switching at once, so crosstalk and supply noise match a real system.

 

Diagram illustrating horizontal bathtub bit error rate results for UCIe-S N2P (2nm) at 40 GT/s, Die 4, Dword 1. Key elements: Measured data points, Extrapolated curve, bit error rate (BER) axis, unit interval (UI) axis, and 25.43 %UI annotation.

40 GT/s Horizontal Bathtub Showing Low BER

What about 64G?

Synopsys has taped out 64G UCIe IP on 2-nm and 3-nm processes, and customers who need that bandwidth density will have it. Implementations at that rate across the industry are still early, though, and there is a lot to learn about running them reliably in production. For many AI, HPC, and networking designs going to tapeout now, 40G gives more bandwidth than 32 GT/s, the maturity of a proven design in Synopsys and customer silicon, and power and latency that fit the system.

For automotive designs, Synopsys offers ISO 26262-compliant die-to-die IP on a 5-nm process, for applications where functional safety and reliability qualification come first.

How to choose

Before you pick a data rate, size the link against three numbers:

  • The bandwidth you actually need, with headroom
  • The latency your coherency or memory protocol can tolerate
  • The power budget at the die edge

Then pick the lowest data rate that meets all three. For a lot of designs today, that's 40G.

Continue Reading

Ask BETA This experience is in beta mode. Please double check responses for accuracy.

End Chat

Closing this window clears your chat history and ends your session. Are you sure you want to end this chat?