Getting Real With High Speed Serdes Devices And Applications
Serdes is everywhere now. If you are designing anything that moves more than a few megabits per second off a board, you will run into it. The basic concept is simple enough on paper: serialize parallel data, send it over a high-speed serial link, deserialize on the other side. But the actual execution is where people lose weeks of their lives. I have seen boards that looked perfect on the schematic fail completely because someone picked the wrong CDR architecture for the channel budget, or didn't account for how thermal drift shifts the PLL phase noise by enough to wipe out margin at the receiver. A modern high-speed Serdes block contains a transmitter with a serializer, a DSP or analog driver, and usually some form of pre-emphasis or CTLE. On the receive side, you get a CDREqualizer, a deserializer, and a clock data recovery circuit. Between them sits whatever protocol layer the IP implements—PCIe, Ethernet, SATA, MIPI, or something proprietary. The data rates I deal with these days sit in the 16 Gbps to 112 Gbps range, and each step up introduces a new set of headaches. The thing nobody tells you early on is that your PCB stackup matters way more than the Serdes IP itself. I once had a project where we spent three weeks debugging intermittent link failures on a 56 Gbps PAM4 lane. The silicon was fine. The PCB fabricator had slightly varnished the copper roughness spec without telling us, and the insertion loss at 28 GHz was enough to erase all our receiver equalizer headroom. We redesigned the stackup, requested tighter conductor roughness tolerance, and the link margin jumped from negative two decibels to positive eight decibels overnight. The Serdes PHY was not the problem. It never was.
Another practical reality: crosstalk between adjacent lanes. At 112 Gbps per lane, aggressive lane-to-lane spacing on your board becomes a liability if your connector or backplane doesn't have good isolation. I have measured near-end crosstalk values that completely killed eye opening on the affected lanes, even though the individual lanes were passing single-ended tests with flying colors. The fix was switching from a standard differential pair layout to a tighter coupled geometry with ground shielding between groups of lanes, which you need to coordinate with your PCB fab upfront.
Common Pitfalls When Using High Speed Serdes Devices And Applications
The first mistake is trusting channel simulations over measurements. Simulators will tell you a channel is good if you feed it ideal S-parameters. Real connectors age. Real cables get bent past their rated radius. Real PCB materials absorb moisture and shift impedance. I always recommend characterizing your actual channel hardware with a vector network analyzer before you commit to a Serdes design. A five-minute TDR sweep can save you months of debugging later. The second mistake is ignoring power supply noise on the Serdes analog sections. A clean 1.0-volt rail sounds fine until you pull a spectrum and find a 5-millivolt peak at the PLL reference frequency harmonics. That noise folds directly into the jitter budget. I have seen projects use standard LDOs on Serdes rails when a low-noise switched regulator or an entirely separate power domain was needed. The datasheet numbers look acceptable. The system performance does not. A third issue is firmware configuration. Most Serdes IPs ship with reasonable defaults, but those defaults assume a typical channel. If your channel is unusually lossy or has significant reflections, the default CTLE and DFE settings will be suboptimal. Some vendors provide channel assessment tools that auto-tune the receiver based on measured S-parameters. Others require you to manually walk through the equalizer settings, which is slow and error-prone. Know what you are working with before you start tuning.
Get the Full Details
When Serdes Is The Wrong Tool
I need to be honest about something. High-speed Serdes is not a universal solution. At data rates below about 2.5 Gbps per lane, parallel interfaces or lower-speed serialized protocols are often simpler and cheaper. The power consumption of a 56 Gbps PAM4 Serdes block can easily exceed one watt per lane, and that heat becomes a serious thermal management problem in dense packaging. I have walked away from Serdes designs in favor of standard LVDS or even CMOS parallel links when the throughput requirement was modest and the board real estate or thermal budget was tight. Another scenario where Serdes struggles is in harsh electromagnetic environments. Aerospace and automotive applications sometimes require more robust signaling than what Serdes can provide under extreme interference. The equalization techniques that recover signals at 112 Gbps depend on predictable channel behavior, and a highly reflective or noisy channel can overwhelm even the most aggressive DSP-based receiver. In those cases, slower, more redundant signaling tends to be more reliable. If you are working with Serdes today, start by understanding your actual channel, not the simulation. Measure the board, characterize the connector, check your power integrity, and configure the PHY for your real conditions. The theory is well documented. The practice is a lot messier, and the differences show up in reliability, not just performance numbers.
