What Is SerDes? Serializer/Deserializer Chips Explained

SerDes (Serializer/Deserializer) is a pair of functional blocks — usually built into a chip — that converts data between parallel form, where many bits move side by side on separate wires, and serial form, where those same bits travel one after another over far fewer wires at much higher speed. It’s the technology that lets modern chips move enormous amounts of data between each other, or across a data center, without the box of ribbon-cable-style wiring that parallel buses would otherwise require.

Why parallel data doesn’t scale

Early computer buses moved data in parallel because it seemed like the obvious way to go fast: send 8, 16, or 32 bits at once, one per wire, and you move that many bits per clock cycle. The problem shows up as speeds increase. Signals on different wires don’t arrive at exactly the same instant — a mismatch called skew, caused by tiny differences in wire length and electrical characteristics — and at high enough clock rates, that skew becomes large relative to the time between bits, corrupting the data. Parallel buses also demand a lot of physical space: a 32-bit-wide bus needs at least 32 signal wires (often paired with ground wires to control interference), which becomes impractical as chips need to move data faster and connectors need to shrink.

SerDes sidesteps both problems by sending one bit at a time over a single differential pair of wires, but doing so at a clock rate far higher than a parallel bus could sustain reliably. The serializer at one end takes a wide parallel word and shifts it out one bit at a time onto the serial line; the deserializer at the other end samples that fast serial stream and reassembles it back into a parallel word for whatever logic consumes it next. Because there’s only one signal path to keep synchronized instead of dozens, that path can run drastically faster without skew becoming a limiting factor.

The clock recovery problem

A serial link doesn’t have the luxury of a separate wire carrying a clock signal alongside the data — that would reintroduce the exact skew problem SerDes exists to avoid. Instead, the receiving side has to recover timing information from the data stream itself, a technique called Clock and Data Recovery (CDR). This generally requires the transmitted bit pattern to guarantee enough signal transitions for the receiver to lock onto — which is why serial links typically encode raw data using a line code (schemes like 8b/10b or 64b/66b) before transmission, trading a small amount of bandwidth overhead for a data pattern that never goes too long without a transition the receiver can use to stay synchronized.

Where SerDes shows up

SerDes links are everywhere data needs to move fast between two points: PCIe lanes, NVLink connections between GPUs, high-speed Ethernet, and the chip-to-chip links inside a chiplet-based processor package all rely on SerDes at the physical layer, even though each defines its own protocol and encoding scheme on top. A modern data-center GPU or networking ASIC can carry dozens to hundreds of individual SerDes lanes, each one an independent high-speed serial link, aggregated together to deliver the total bandwidth a workload needs — see what a system-on-chip is for how many such interfaces get integrated onto one die.

The tradeoff for that raw speed is per-link complexity: each SerDes lane needs analog circuitry to shape and equalize the signal, clock recovery logic, and encoding/decoding hardware, all of which costs die area and power that a simple parallel wire wouldn’t. This is why SerDes became dominant on external, high-speed links first — where the wire-count savings clearly outweighed the added circuit complexity — while comparatively short, low-speed on-chip connections still sometimes use wider, simpler buses.

Serial vs parallel, side by side

	Parallel bus	Serial link (SerDes)
Wires needed	One per bit, plus grounds	One differential pair per lane
Limited by	Signal skew across wires	Per-lane analog signal integrity
Clock	Often a shared wire	Recovered from the data stream
Scaling to higher bandwidth	Add more wires (space-limited)	Add more lanes or raise the per-lane rate
Circuit complexity per connection	Low	Higher (encoding, CDR, equalization)
Typical modern use	Short, low-speed on-chip buses	PCIe, Ethernet, GPU interconnects

Scaling bandwidth: more lanes or faster lanes

Once a link is built on SerDes, there are two independent ways to add bandwidth: increase the number of parallel serial lanes, or increase the bit rate each individual lane runs at. Interconnect standards typically do both across successive generations — PCIe, for instance, both doubles its per-lane signaling rate and offers configurations with more lanes as the standard evolves — because pushing a single lane’s clock rate indefinitely runs into the same physical signal-integrity limits that made serial links necessary over parallel buses in the first place. This is also part of why bandwidth between components is often described in aggregate terms (total lanes times rate per lane) rather than a single number, similar to how HBM versus GDDR memory bandwidth is often expressed as many parallel channels working together rather than one very fast one.

The takeaway

SerDes solves a problem parallel buses eventually can’t: past a certain speed, keeping many wires perfectly synchronized becomes harder than running one very fast serial link and recovering timing from the data itself. That tradeoff — fewer wires, higher per-wire complexity — is why nearly every high-speed chip-to-chip and chip-to-network connection in modern computing, from PCIe to GPU interconnects, is built on SerDes underneath whatever protocol runs on top of it.