Retimers Replacing Redrivers As Signal Speeds Increase

Redrivers are running out of steam as more devices are connected over high-speed protocols.

popularity

Retimers are undergoing a renaissance as new PHY protocols prove too demanding for redrivers.

Redrivers and retimers both have been used to extend wired signal reach over the years. But redrivers have dominated this space due to their relative simplicity and lower cost. That balance is beginning to change.

“A retimer represents three things no one wants in their system — area, cost, and consideration for where it goes,” said Matt Jones, general manager of IP cores at Rambus. “Then you throw in power, and the first thing that everyone thinks is, ‘How do I get around using one of these?’ But the reality is that they’re becoming an absolute necessity.”

A few protocols always have relied on retimers for bandwidth, while the remainder worked fine with redrivers. Newer generations of USB and PCIe have pushed the limits, however. SerDes channels — especially those relying on newer modulation schemes like PAM-4 and higher no longer have ability to drive far enough without a retimer.

“There are three major SerDes ecosystems: USB, PCIe, and OIF/802.3,” explained Brian Holden, vice president of standards at Kandou. “The OIF/802.3 Ethernet world never got into redrivers, as they have always been pushing the speeds. That ecosystem has been shipping 56 Gb/s SerDes for some years and is working on 112 Gb/s now. USB long has supported redrivers, but it is being forced to move to retimers with USB4. PCIe also supports the use of redrivers in their links, but PCIe 5.0 has pretty much stopped that, and 6.0 will completely end their use.”

All about the PHY
The push for faster communications channels has driven PHY technology to rely increasingly on SerDes variants, and the measure of signal quality is how clean the eye diagram is. As signals travel down the line, their quality degrades, leading to the notion of reach, which is how far the signal can go before it no longer can be received reliably.

Fig. 1: A classic eye diagram for a two-level NRZ signal. Source: Andrew D. Zonenberg - Own work, CC BY 4.0

Fig. 1: A classic eye diagram for a two-level NRZ signal. Source: Andrew D. Zonenberg – Own work, CC BY 4.0

Designers can extend that reach, however, if there is a way to freshen up the signal so that it can go further — kind of like a repeater. In SerDes parlance, the degradation shows up as the eye closing, and they want something that will open the eye back up. In practice, that can be difficult to do.

It’s hard enough for a basic two-level SerDes signal (so-called NRZ), but newer modulation schemes like PAM-4, PAM-8, and beyond make it even harder. In those cases, there are multiple eyes, all of which have to be clean in order for the data to be recovered.

The “simplest” solution would be to shorten traces and bring things closer together. That’s usually difficult at best — and often impossible. A look at the data center helps to explain why that might be the case.

The data center as an example
A rack in a data center will consist of slots for computing blades. Historically, there’s been a top slot for a switch that takes PCIe signals from the blades and routes them to other blades or to other racks.

The mechanical specs for these racks are well established. “As you look at a server architecture, the rack size hasn’t changed and the motherboard size hasn’t changed,” noted Jones.

There are two parts of this setup that need attention — getting signals from the CPU or other computing component to the edge of the board where the I/O is, and then getting that signal from the I/O to some other I/O over a cable.

In the first case, the distance the signal must travel is bounded. PCBs are of a standard size, so while there can be some variation in the distance between the CPU and the edge, that variation will be limited. “The CPU set is going to be middle off-center to ensure that you’re getting the best use of the overflow of the fan for additional cooling,” said Jones. “You’re still going to have the I/O and the plugs at the edge of the board.”

In the second case, we don’t know where the signal will go. It’s presumably going to end up at the switch, but it makes a difference which board the signal is coming from. It should be possible to place a blade in any slot, so the worst-case situation is where the board is far from the switch. That used to be a case of the board being at the bottom and the switch being at the top. “When you start looking at things like top of rack to bottom of rack, you’d be on the hairy edge there, if not well over budget,” said Jones.

In a rare instance of being able to change that distance, switches are moving to the middle of the rack, cutting the worst-case distance roughly in half. “Even in the classic cases of Ethernet or optics, you see the top of rack switch moving to the middle of the rack,” said Jones.

But, beyond that, this is a fixed architecture. And there’s little to no chance that the mechanical dimensions will ever change, given the amount of existing infrastructure already in place. The only thing that’s likely to change in the future is the channel material. “The nature of that interconnect will change from copper to optical over time to solve that problem,” said Jones.

Signals must be able to traverse that distance successfully, regardless of any bandwidth increases. Ideally, a signal can go from its driver to the receiver with no help. That’s no longer feasible for many situations. As a result, some means of cleaning up the signal is required to push it further.

There are two ways of extending a signal in the communications world — redrivers and retimers. Redrivers have been more common. But retimers, which are not new, are proliferating. In fact, they are replacing redrivers in many applications.

Redrivers are simple but have limits
A redriver is an analog circuit that simply attempts to clean up a signal. It uses equalization to compensate for how the channel degrades the signal, and it amplifies the signal. But it also amplifies noise. And while it can reduce some kinds of jitter, it can add some of its own, making it a mixed bag.

Fig. 2: Simple redriver block diagram. Source: Kandou

Fig. 2: Simple redriver block diagram. Source: Kandou

Placement of a redriver can be tricky. While it might be tempting to put the redriver right in the middle of the channel, the signal will have been degraded by that point, and pushing it farther down may provide better performance.

But a redriver’s performance will depend on the nature of the entire line, from source to destination. In a fixed system, the optimal placement can be determined by math and simulation. That simulation must take into account not just the length and type of channel, but also any discontinuities, like pins and sockets.

“If you’re using a redriver, you need to know the channel from one chip to the other chip and what’s in between,” explained Priyank Shukla, staff product marketing manager at Synopsys. “Is there a connector? How is the connector laid out? What’s the discontinuity in the channel? You need to know the system before you start using a redriver.”

This becomes a problem in a modular architecture like a data center rack. In that case, it’s necessary that any board be able to drive any other board, regardless of who made the boards, who built the rack, or which slots are used. That makes it theoretically impossible to determine the best placement. If a board in such a rack uses a redriver, then it may not interoperate properly with other boards.

In addition, redrivers can’t react to any changes in the quality of the channel, because a redriver configuration is static.

What’s good about redrivers, though, is they’re simple, cost-effective, and they add very little latency to the signal.

Retimers: Complex but more capable
Retimers, by contrast, don’t simply try to clean up a signal. Instead, they create a fresh copy of the signal. “To open the eyes, you need retimers,” said Nigel Alvares, vice president, solutions marketing at Marvell Semiconductor. “So you’ll see them proliferate as speeds go up and voltages go down. It’s a key building block, and we’re seeing more and more use cases for it.”

Fig. 3: A signal as transmitted and received with no redriver or retimer (left two diagrams). A redriver (third image) brings signal amplitude back, but the acquired noise remains. A retimer (far right image) creates a completely new signal, comparable to that which was originally transmitted. Source: Kandou

Fig. 3: A signal as transmitted and received with no redriver or retimer (left two diagrams). A redriver (third image) brings signal amplitude back, but the acquired noise remains. A retimer (far right image) creates a completely new signal, comparable to that which was originally transmitted. Source: Kandou

That means pulling the clock out of the signal to get to the data stream itself. That data stream is then re-serialized with the clock newly re-inserted. This is done in a protocol-specific way. So while redrivers may work on any line, PCIe retimers can be used only on a PCIe line, for example.

Fig. 4: Simplified retimer block diagram. It’s significantly more complex than a redriver. Source: Kandou

Fig. 4: Simplified retimer block diagram. It’s significantly more complex than a redriver. Source: Kandou

The “protocol-awareness” of retimers can add significant latency to the signal. Within a clock cycle, it’s possible to push and pull signals back and forth to eliminate skew. But in so doing, it may be necessary to pull an entire packet off the line, verify the checksum, repacketize the data, and then send it out afresh.

“With Ethernet or any of those similar protocols, you don’t transmit individual bits. You transmit packets, which are hundreds or thousands of bits,” noted Todd Westerhoff, product marketing manager in Siemens EDA’s PCB Division.

How those translate into clock cycles may vary, however. “Clock cycles are not a good way to estimate latency,” cautioned Paul Wilson, director of marketing at Kandou. “It depends on the reference clock, which varies per protocol and baud rate.”

Being protocol-aware also allows a retimer to be optimized for that protocol. “If we talk specifically about PCIe, the transmitter has specific knobs for a channel, and a retimer knows those knobs,” said Shukla. “Ethernet doesn’t have similar knobs. That’s why a PCIe retimer wouldn’t work in an Ethernet ecosystem.”

The protocol also may require link training, both on the incoming and outgoing links. That makes the complexity of a retimer much higher than that of a redriver.

The benefit of this complexity, however, is that the output signal won’t be just a cleaned-up version of the old signal. It will truly be a new signal. The loss budget is completely reset, and in theory one can repeat this over and over indefinitely.

This is helpful when calculating link reliability, because each segment will be independent. “When I’m modeling and simulating, I can treat them as independent links that have independent failure probabilities, and I can just do the math,” said Westerhoff.

That contrasts with a redriver, which can never quite get the quality back fully, so that subsequent redrivers will be less effective for each additional downstream redriver. And the reliability must be calculated for the entire link, not just the segments between redrivers.

“Redrivers are essentially analog signal improvement devices,” said Westerhoff. “And you can take a signal and enhance it from an analog perspective only so many times before you lose it.”

Retimer latency can add up, however. Simply adding retimers can have a significant impact on overall latency. That may not make as much of a difference for a unidirectional signal, but for bi-directional channels, the accumulated round-trip latency can be a problem if not managed.

The complexity can result in higher power as well, although this appears to be protocol-dependent. “In the case of PCIe, the retimer workload is pretty heavy,” noted Jones. That translates into roughly twice the power per channel of a redriver, as Shukla pointed out.

A comparison for USB, on the other hand, has redrivers and retimers with more or less the same power. “Comparing the KB8001 [Kandou USB retimer] average power consumption when configured for USB3.2-only mode at 10 Gbps (one lane) vs. a typical redriver solution is roughly the same,” said Wilson. “The KB8001 is 324 mW vs. TI’s TUSB1002A at 330 mW.”

Retimer-cable-retimer
On a data center board, it’s clearly beneficial to put a retimer right before the I/O drivers. That ensures the cleanest possible signal leaving the board. But the distance between the CPU and the edge is also becoming an issue, so a dual-retimer strategy is used, with a retimer between the CPU and the edge retimer.

Fig. 5: A simplified data-center example. Retimers in the middle of the on-board signal help the signal to reach the I/Os. Retimers right before the I/O ensure the cleanest signal going out onto the cables. Retimers right at the edge of the receiving board maximize interoperability by cleaning up a received signal regardless of where it originated. Source: Bryon Moyer/Semiconductor Engineering.

Fig. 5: A simplified data-center example. Retimers in the middle of the on-board signal help the signal to reach the I/Os. Retimers right before the I/O ensure the cleanest signal going out onto the cables. Retimers right at the edge of the receiving board maximize interoperability by cleaning up a received signal regardless of where it originated. Source: Bryon Moyer/Semiconductor Engineering.

Because the positioning of the middle retimer isn’t critical, it’s easier to re-use an existing board layout for many different designs or generations. If a redriver was used, then each board might need to be re-optimized, and that’s a significant incremental development cost.

“You could move all of this stuff, but it’s going to cost you redesign,” Jones pointed out. “And that’s money and time — every time the speed bumps up. So when you go from PCIe Gen 4 to Gen 5, do you really want to go through a whole motherboard design cycle?”

It also promotes interoperability, because the retimers don’t care what’s driving them or what they’re driving. “A retimer gives you this flexibility that you can place it in any system and it will work,” noted Shukla. “A retimer adapts itself, and it ensures interoperability across different ecosystem vendors.”

Once off the board, it’s no longer possible to put a retimer just anywhere. While USB has active cables, PCIe does not, so there’s nowhere to put a retimer except at the end of the cable link. So a typical configuration to ensure interoperability is to put a retimer at the beginning of any such link, like at the edge of the board, and then again at the receiver.

“Because of that lack of determinism in the link length, you’re very likely to see a retimer on both the transmit and the receive side of any of those arrangements,” said Jones. “So you’re going: retimer-cable-retimer. And the retimers are going to be as close to the edge as possible.”

Redrivers have been preferred based on their simplicity, lower cost, and lower power. In general, even now, if a redriver can work, then it will be used. It’s just that the number of situations where that works is decreasing as speeds increase.

“In a choice between the redriver and retimer, I’d always rather take a redriver,” said Westerhoff. “It’s simpler, it’s cheaper, and it doesn’t insert any appreciable delay in the system. The problem is, when things get fast enough and the lines get long enough, you just can’t continue to regenerate the signal with enough margin so that you can rely on that link.”

Shukla agreed. “If I know my system completely, and I’m 100% certain that with the redriver I can ensure system functionality, I will go with the redriver because I will save power. But it will be a closed ecosystem. My board will work only with my components. A retimer makes this system 100% open.”

Automobiles are the exception
The one environment that appears not to welcome retimers is the new electrified automobile. Cabling is a significant consideration both for weight and for cost, and the distances are forcing the use of more expensive shielded cable.

One might think using retimers could shorten links, enabling the use of unshielded cable. But the use of those retimers would negate the cable cost savings.

More importantly, each active component affects the reliability of the car — a consideration arising out of the safety-critical nature of the system. By definition, it’s more reliable to go with longer shielded cable than to add retimers.

It may be easier to calculate link reliability with a retimer. But that’s just the reliability of that one link. The automotive concern relates to the reliability of the entire vehicle — a very different calculation.

“When you’re building a something in the car, you’re not building a PC,” said Tom Wong, director of marketing, design IP at Cadence. “Every time you introduce another piece of electronics, you have to worry about failure rate over time. So if I have to do a design without the retimer versus the retimer, I would rather solve the problem with a shielded cable that is passive.”

The harsh road environment doesn’t help either. “If I were building a computer or network, I would just use short reach any time and throw a retimer in and do a nice clock recovery,” Wong said. “But I don’t have shake, rattle, and roll — and high temperature — in the computer data center.” So it appears that retimers will not be appearing in vehicles.

Cars aside, the tremendous growth in connectivity over both PCIe and USB is driving up retimer volumes. Although redrivers won’t disappear anytime soon, as speeds get ever faster, their days do appear to be numbered.



1 comments

Tanj says:

Seems like it should be possible for a retimer to clean up the signal with less delay than needed for CRC. Can it not, with a delay of a few clocks, repeat its best guess for the correct waveform and recenter the timing of the transitions as well as the levels in protocols such as PAM4? Most deserializers are making decisions like that, prior to the FEC and CRC.

Yes, the error rate would be slightly higher. Logically, if the BER at the reach of each retimer is very small, eps < 1e-6, and the output of each retimer is a locally valid and correctly formed best guess, then N retimers should result in an error rate of N*eps.

That is far better than with redrivers, and most likely low enough to allow the end-to-end recovery protocols to still work correctly. Worth it to keep latency under control?

Leave a Reply


(Note: This name will be displayed publicly)