---
title: "Why do fast serial links use line codes like 8b/10b?"
topic: "Line codes"
answer: "To keep edges coming so the receiver can find its clock, and to keep the line balanced so its coupling caps don’t charge up. 8b/10b does both by sending each byte as 10 bits, which is why SATA’s 6 Gb/s carries 600 MB/s, not 750. Faster links scramble the bits instead and add a short header to every 64 or 128, for 1.5 to 3%."
url: "https://nearfieldnotes.com/notes/line-codes/"
site: "Near Field Notes"
author: "Michael Walker"
note: 26
family: "Signal integrity"
published: "2026-11-08"
revised: "2026-11-08"
revision: 1
video: "https://nearfieldnotes.com/videos/line-codes/"
---

Note 26 · [Signal integrity](https://nearfieldnotes.com/families/si/) · Rev 1 · [Watch the video · 3:07](https://nearfieldnotes.com/videos/line-codes/)

Line codes

# Why do fast serial links use line codes like 8b/10b?

**Short answer:** To keep edges coming so the receiver can find its clock, and to keep the line balanced so its coupling caps don’t charge up. 8b/10b does both by sending each byte as 10 bits, which is why SATA’s 6 Gb/s carries 600 MB/s, not 750. Faster links scramble the bits instead and add a short header to every 64 or 128, for 1.5 to 3%.

The figure sends 4 KB of zero bytes down one SATA lane two ways. As plain bits the line sits low for 5.46 µs. Its caps charge, and by the block’s last bit a 0 is 2.7 mV from the receiver’s threshold.

Through 8b/10b every zero byte goes out as 1001110100. The block takes 6.83 µs, and its last 0 still sits at −250 mV.

**Note 26’s opening figure: 4 KB of zeros through the caps.** Plain bits and 8b/10b on one SATA lane

![Note 26’s opening figure: 4 KB of zeros through the caps](https://nearfieldnotes.com/notes/line-codes/fig-opening.png)

*What the figure shows:* Receiver voltage on a SATA lane as 4 KB of zero bytes goes through its 12 nF coupling caps, from 0.4 µs before the block to 7.3 µs after its start. Sent as plain bits, the line holds low for 5.46 µs and a 0 sinks from −252 mV to −2.7 mV, then the bits after it sit off center. Through 8b/10b the block takes 6.83 µs, the line keeps switching, and its last 0 is at −250 mV.

Receiver voltage at 6 Gb/s through 12 nF on each wire, from 0.4 µs before the block. Each band spans the lowest and highest voltage at that moment. The bracket marks the block and the dashed line is the 0 V threshold. Real SATA scrambles its data before 8b/10b, so plain bits on SATA are a what-if.

**The numbers**

*4 KB of zero bytes at 6 Gb/s through 12 nF on each wire.*

| Sent as | 4 KB takes | Edges in the block | A 0 before the block | Last 0 of the block |
|---|---|---|---|---|
| Plain bits | 5.46 µs | 0 | −252 mV | −2.7 mV |
| 8b/10b | 6.83 µs | 24,575 | −250 mV | −250 mV |

## A SATA lane

*One pair each way, and no clock wire*

A SATA drive talks to its host over two pairs of wires, one for each direction. Each pair carries one bit at a time as the difference between its two wires, 6 billion bits a second at SATA’s top rate.

There is no clock wire. The receiver has to work out where each bit starts from the bits themselves, from the moments the line switches.

Each wire also passes through a small capacitor on the board, up to 12 nF in SATA’s spec. The caps block DC, so the drive and the host can each keep their own DC level.

**Fig. 26: A SATA SSD, cover off.**

![Fig. 26: A SATA SSD, cover off](https://nearfieldnotes.com/notes/line-codes/fig-26.png)

*What the figure shows:* Figure 26: a 2.5-inch SATA SSD with its cover off and its data cable plugged in. A close-up of the board behind the data plug shows two pairs of traces, pair A and pair B, each running from the plug through a pair of small AC coupling capacitors toward the controller. The data plug face on has seven contacts: ground, A plus, A minus, ground, B minus, B plus, ground. None of them carries a clock.

A 2.5-inch drive to the SFF-8201 outline, its board laid out after a retail SATA SSD. Behind the data plug each pair runs through two AC coupling caps toward the controller. The plug’s seven contacts are the two pairs and three grounds.

**The numbers**

*The SATA device plug’s signal contacts, from SATA 1.0a Table 3.*

| Contact | Carries |
|---|---|
| S1 | GND |
| S2 | A+ |
| S3 | A− |
| S4 | GND |
| S5 | B− |
| S6 | B+ |
| S7 | GND |

Every wave on this page comes from one pair. The driver swings each wire 0.25 V, the two in opposite directions, behind 50 Ω. Each wire passes a 12 nF cap and ends in 50 Ω at the receiver, which sees ±250 mV: SATA’s nominal 500 mV peak to peak.

The receiver reads a 1 when the plus wire is higher and a 0 when it is lower. That threshold, 0 V between the wires, is the line every chart here measures against.

**Fig. 26b: One SATA pair.**

![Fig. 26b: One SATA pair](https://nearfieldnotes.com/notes/line-codes/fig-26b.png)

*What the figure shows:* Figure 26b: one SATA pair. A driver sends each of its two wires, plus and minus, through 50 ohms and a 12 nF capacitor to the receiver, where each wire ends in 50 ohms to ground. The receiver reads the difference between the wires.

Every wave on this page comes from this circuit at 6 Gb/s, with 40 ps edges. The cable and the boards’ traces are left out.

**The numbers**

| Part | Value |
|---|---|
| Driver | ±0.25 V on each wire, opposite, behind 50 Ω. 40 ps edges |
| Coupling | 12 nF in series on each wire, SATA’s largest |
| Termination | 50 Ω from each wire to ground |
| Receiver | Reads plus minus minus: a 1 above 0 V, a 0 below |
| Swing | ±250 mV at the receiver, 500 mV peak to peak: SATA’s nominal |
| Rate | 6 Gb/s, 167 ps a bit |

## Edges for the clock

*The first bits of 4 KB of zeros*

A receiver with no clock wire runs its own clock and nudges it into line at every edge, each time the line switches between 1 and 0. Between edges it has nothing to correct against.

A block of zero bytes sent as plain bits has no edges at all for 5.46 µs. 8b/10b sends each zero byte as 1001110100, which switches six times every 10 bits.

The block gets 24,575 edges, and never more than 3 equal bits in a row.

**Fig. 26c: The block’s first bits.**

![Fig. 26c: The block’s first bits](https://nearfieldnotes.com/notes/line-codes/fig-26c.png)

*What the figure shows:* Figure 26c: the first bits of the 4 KB block at the receiver, with the bits on the line above each trace. Plain, the line falls to a 0 and stays there: no edges in the whole block. Through 8b/10b every zero byte goes out as 1001110100, so the line keeps switching: 24,575 edges in the block.

Bits counted from the block’s first, with the line’s bits drawn above each trace: a 1 filled, a 0 left empty. The edge counts are for the whole 4 KB block.

**The numbers**

| Sent as | First line bits of the block | Edges in the block | Longest run |
|---|---|---|---|
| Plain bits | 00000000000000000000… | 0 | 32,768 |
| 8b/10b | 10011101001001110100… | 24,575 | 3 |

## Why the line sinks

*12 nF on each wire, 200 Ω around the loop*

The caps pass changes and block anything steady. Hold one level and the caps charge toward it, so the receiver sees the bit fade toward the threshold. The time constant sets how fast:

`τ = R C`

where τ: time constant of the coupling caps (s); R: resistance around the loop: both 50 Ω drivers and both 50 Ω ends (Ω); C: the two 12 nF caps, in series (F).

`= 200 Ω × 6 nF = 1.2 µs = 7,200 bits at 6 Gb/s`

R counts both drivers’ 50 Ω and both ends’ 50 Ω, and the two caps act in series as 6 nF. A held bit fades as

`V = V_0 e^(− t / τ)`

where V: voltage left on a held bit at the receiver (V); V_0: its voltage when the run starts (V); t: time the bit has been held (s); τ: time constant of the coupling caps (s).

`= 252 mV × e^(−5.46 µs/1.2 µs) = 2.7 mV`

That is the plain zero block at its last bit, 5.46 µs in. The full circuit lands on the same 2.7 mV.

8b/10b never lets a run pass 5 bits, which keeps 99.93% of the voltage. 64b/66b, below, can run as long as 66 bits, which keeps 99.1%.

**Fig. 26d: Voltage left after a run.**

![Fig. 26d: Voltage left after a run](https://nearfieldnotes.com/notes/line-codes/fig-26d.png)

*What the figure shows:* Figure 26d: the share of a held bit's voltage left at the receiver after a run of identical bits, against the run's length on a log scale, for 12 nF caps at 6 Gb/s. It stays near 100% for short runs and falls to 37% at 7,200 bits. 8b/10b's longest run, 5 bits, keeps 99.93%. 64b/66b's longest possible, 66, keeps 99.1%. 4 KB of zeros sent plain, 32,768 bits, leaves 1.1%.

From the formula, for this lane at 6 Gb/s, on a log scale of bits. The gray dot is the full circuit’s result for the opening figure’s plain block.

**The numbers**

*V ÷ V₀ = e^−t/τ, τ = 1.2 µs = 7,200 bits at 6 Gb/s.*

| Run | Bits | Voltage left |
|---|---|---|
| 8b/10b’s longest run | 5 | 99.93% |
| 64b/66b’s longest possible run | 66 | 99.1% |
| One time constant | 7,200 | 37% |
| 4 KB of zeros, plain | 32,768 | 1.06% by the formula, 1.06% from the full circuit |

## 8b/10b

*IBM, 1983*

IBM published 8b/10b in 1983. It sends every byte as a 10-bit code from a table, each code picked to switch often and stay balanced. SATA has used it at every speed.

**Fig. 26e: “SATA” through the encoder.**

![Fig. 26e: “SATA” through the encoder](https://nearfieldnotes.com/notes/line-codes/fig-26e.png)

*What the figure shows:* Figure 26e: the letters S, A, T, A through SATA's 8b/10b encoder. S, byte 53h, goes out as 1100100101, as many 1s as 0s. A, byte 41h, goes out as 0111010101, +2. T, byte 54h, goes out as 0010110101, as many 1s as 0s. A, byte 41h, goes out as 1000100101, −2. The two A's go out differently. Below, the count of 1s minus 0s along the 40 line bits stays between −1 and +3.

Each byte’s 10-bit code from SATA’s 8b/10b tables, starting from running disparity −1. Below, the count of 1s minus 0s along the 40 line bits.

**The numbers**

*The encoder starts with running disparity −1, as a link does after reset.*

| Letter | Byte | Name | Bits in | On the line | 1s − 0s | Running disparity after |
|---|---|---|---|---|---|---|
| S | 53h | D19.2 | 01010011 | 1100100101 | 0 | −1 |
| A | 41h | D1.2 | 01000001 | 0111010101 | +2 | +1 |
| T | 54h | D20.2 | 01010100 | 0010110101 | 0 | +1 |
| A | 41h | D1.2 | 01000001 | 1000100101 | −2 | −1 |

8b/10b

### Every byte as 10 bits, balanced

**Field marks.** Each code has five 1s and five 0s, or six of one and four of the other. A byte whose code is unbalanced has two codes, and the encoder picks the one that pulls the count of 1s minus 0s back toward zero. That running count is the running disparity. The two A’s in Fig. 26e go out as 0111010101 and 1000100101.

**Look-alike.** TMDS, the 8-to-10-bit code of DVI and HDMI. It also sends 10 bits a byte and keeps the line balanced, but it was built to cut the edges on a video lane, and those links send their clock on a pair of its own. [Note 14](https://nearfieldnotes.com/notes/phy-link/) follows it.

**Range.** The longest run of equal bits is 5, and the count of 1s minus 0s stays inside a band 6 wide. A fifth of the line carries no data.

**Habitat.** SATA at 1.5, 3 and 6 Gb/s, USB 3.0, PCIe 1.x and 2.0, 10G Ethernet’s XAUI, Fibre Channel up to 8GFC and DisplayPort 1.x. SATA scrambles its data before coding it, to spread its emissions.

## Where each byte starts

*The comma*

Edges let the receiver find each bit. It also has to find where each 10-bit code starts. 8b/10b keeps 12 codes aside for control, the K characters, and three of them start with a pattern no data can make: the comma.

Of those three, SATA uses only K28.5, as the first byte of its ALIGN primitive. The receiver slides along the bits until it sees 0011111 or 1100000, and from there it counts in tens.

A million random bits through the encoder hold no commas at all, and the stream in Fig. 26f holds exactly one.

**Fig. 26f: A comma among data.**

![Fig. 26f: A comma among data](https://nearfieldnotes.com/notes/line-codes/fig-26f.png)

*What the figure shows:* Figure 26f: seven characters as SATA's 8b/10b encoder sends them, one under another. Only K28.5 starts with 0011111, two 0s and five 1s, the comma. Read as one stream, no other seven bits in a row match it or its opposite, 1100000.

SATA’s 8b/10b codes for six data bytes and K28.5, running disparity carried from one to the next. 4Ah’s code is the one in [Note 14](https://nearfieldnotes.com/notes/phy-link/).

**The numbers**

*Running disparity carried from one character to the next, from −1.*

| Character | Byte | On the line |
|---|---|---|
| D10.2 | 4Ah | 0101010101 |
| D3.6 | C3h | 1100010110 |
| D23.0 | 17h | 1110100100 |
| K28.5 | — | 0011111010 |
| D29.2 | 5Dh | 0100010101 |
| D0.0 | 00h | 1001110100 |
| D18.5 | B2h | 0100111010 |

## What 20% costs

*6 Gb/s of line, 600 MB/s of data*

Ten line bits for every eight data bits leave 80% of the line for data:

`B = r × k/n ÷ 8`

where B: data rate, in bytes (B/s); r: line rate (bit/s); k: data bits in a code word (bits); n: line bits in a code word (bits).

`= 6 Gb/s × 8/10 ÷ 8 = 600 MB/s`

SATA-IO quoted 600 MB/s when 6 Gb/s SATA launched in 2009. USB 3.0 and PCIe 2.0 pay the same: 5 Gb/s of line carries 4 Gb/s of data.

The codes that came after spend far less, as the lower bars show.

**Fig. 26g: Line rate and data rate.**

![Fig. 26g: Line rate and data rate](https://nearfieldnotes.com/notes/line-codes/fig-26g.png)

*What the figure shows:* Figure 26g: line rate and data rate per lane for six links. SATA, 8b/10b: 4.8 of 6 Gb/s. USB 3.0, 8b/10b: 4 of 5 Gb/s. PCIe 2.0, 8b/10b: 4 of 5 Gb/s. PCIe 3.0, 128b/130b: 7.88 of 8 Gb/s. USB 3.1 Gen 2, 128b/132b: 9.7 of 10 Gb/s. 10GBASE-R, 64b/66b: 10 of 10.3125 Gb/s.

Per lane, from each link’s line rate and its code. The darker part of each bar carries data, the lighter part is the code’s. Protocol headers and packets take more on top.

**The numbers**

*Per lane, before the protocol’s own headers.*

| Link | Code | Line rate | Data rate | Not data |
|---|---|---|---|---|
| SATA | 8b/10b | 6 Gb/s | 4.8 Gb/s | 20% |
| USB 3.0 | 8b/10b | 5 Gb/s | 4 Gb/s | 20% |
| PCIe 2.0 | 8b/10b | 5 Gb/s | 4 Gb/s | 20% |
| PCIe 3.0 | 128b/130b | 8 Gb/s | 7.877 Gb/s | 1.54% |
| USB 3.1 Gen 2 | 128b/132b | 10 Gb/s | 9.697 Gb/s | 3.03% |
| 10GBASE-R | 64b/66b | 10.31 Gb/s | 10 Gb/s | 3.03% |

## Scramble, then add a header

*Ethernet, 2002*

At 10 Gb/s a fifth of the line was too much. 10G Ethernet’s XAUI ran four lanes of 8b/10b at 3.125 GBd, 12.5 GBd of line for 10 Gb/s of data. Its single-lane serial form needed something leaner.

64b/66b scrambles the data, so long runs become rare, and puts a 2-bit header in front of every 64 bits. The share of the line that carries no data is

`s = (n − k)/n`

where s: share of line bits that aren’t data (%); n: line bits in a code word (bits); k: data bits in a code word (bits).

`= 2/66 = 3.03% for 64b/66b, 2/130 = 1.54% for 128b/130b`

**Fig. 26h: Zeros through 64b/66b.**

![Fig. 26h: Zeros through 64b/66b](https://nearfieldnotes.com/notes/line-codes/fig-26h.png)

*What the figure shows:* Figure 26h: the first three 64-bit blocks of the 4 KB zero block through 64b/66b. Each goes in as 64 zeros and comes out as a 01 header and 64 scrambled bits: 01 0011001001001100011010011111010010111010111101000001010101011111, 01 0111101001101111100101010000010000000011111100011000100011110100, 01 1001001111100010101000100001000100010101010001011111100001100000.

The first three blocks of the 4 KB zero block, each 64 zero bits in. A 1 is filled, a 0 left empty. The scrambler’s state comes from the traffic before the block.

**The numbers**

*Longest run in the whole 4 KB block: 17 bits.*

| Block | Header | 64 scrambled bits |
|---|---|---|
| 1 | 01 | 0011001001001100011010011111010010111010111101000001010101011111 |
| 2 | 01 | 0111101001101111100101010000010000000011111100011000100011110100 |
| 3 | 01 | 1001001111100010101000100001000100010101010001011111100001100000 |

64b/66b

### A 2-bit header on 64 scrambled bits

**Field marks.** The header is 01 for a block of data and 10 for one that starts with control codes. It skips the scrambler, so every 66 bits hold at least one edge, in a place the receiver can find. The 64 bits go through a scrambler, 1 + x³⁹ + x⁵⁸, which mixes each bit with the scrambled bits 39 and 58 places before it.

**Look-alike.** 8b/10b with less overhead. 64b/66b promises no balance, and its longest possible run is 66 bits against 8b/10b’s 5. Scrambling makes long runs unlikely, not impossible.

**Range.** The 4 KB zero block comes out 49.9% ones, with a longest run of 17 bits. 10GBASE-R sends 10 Gb/s at 10.3125 GBd, and the difference is the 3.03%.

**Habitat.** 10G Ethernet from IEEE 802.3ae in 2002, then 40 and 100G Ethernet, 16GFC Fibre Channel, InfiniBand FDR, and USB4 at 10 Gb/s with its error correction off.

## What a scrambler can’t promise

*RFC 2615, 1999*

A scrambler is predictable by design, because the receiver has to undo it. SONET scrambles every frame with the same 127-bit sequence, started over at each frame.

XOR an ordinary packet with that sequence and its bits come out mixed. A packet whose bits already equal the sequence comes out as all zeros. RFC 2615 records that such packets let malicious users cause transition problems on SONET links, and in 1999 it added a self-synchronizing x⁴³ + 1 scrambler for PPP over SONET.

In the explorer below, a 4 KB packet built that way sends 32,768 zeros in a row through SONET’s scrambler alone, with no frame overhead between its rows. Through 64b/66b’s scrambler, whose state depends on all the traffic before, its longest run is 13.

**Fig. 26i: A packet built to match.**

![Fig. 26i: A packet built to match](https://nearfieldnotes.com/notes/line-codes/fig-26i.png)

*What the figure shows:* Figure 26i: SONET's frame-synchronous scrambler, 1 + x⁶ + x⁷, which repeats every 127 bits. An ordinary packet XOR the scrambler goes out mixed, its longest run 6 bits. A packet whose bits equal the scrambler's own sequence comes out as all zeros.

SONET’s frame-synchronous scrambler, 1 + x⁶ + x⁷, from its all-ones start. The first 48 bits of each packet. The scrambler row is the same in both.

**The numbers**

*The first 48 bits, the scrambler started from 1111111 as at a frame’s start.*

| Packet | Bits in | On the line |
|---|---|---|
| Ordinary | 110100001101000011010001000000001100001101100101 | 001011101101010011001001010100010010011100111100 |
| Built to match | 111111100000010000011000010100011110010001011001 | 000000000000000000000000000000000000000000000000 |
| The scrambler | 111111100000010000011000010100011110010001011001 | — |

## Two header bits or four

*PCIe 3.0 and USB 3.1*

PCIe 3.0 needed twice PCIe 2.0’s bandwidth. 10 GT/s with 8b/10b would have given 8 Gb/s a lane, but 10 GT/s was judged too hard on existing boards. PCIe 3.0 ran 8 GT/s instead and swapped 8b/10b for 128b/130b, a 2-bit header on 128 scrambled bits: 7.88 Gb/s of data a lane.

USB 3.1 went to 10 Gb/s in 2013 with 128b/132b. Its header has four bits, which cost as much as 64b/66b’s two: 3.03% of the line.

**Fig. 26j: A flipped header bit.**

![Fig. 26j: A flipped header bit](https://nearfieldnotes.com/notes/line-codes/fig-26j.png)

*What the figure shows:* Figure 26j: block headers with one bit flipped on the way. 64b/66b's two header bits are 01 for data and 10 for control. A flip gives 00 or 11, and each of those can come from either, so the receiver knows the block is bad but not what it was. USB's 128b/132b header is 0011 for data and 1100 for control, which differ in all four bits. A data header with any one bit flipped is still one bit from 0011 and three from 1100, so it is read as data.

Each header with one bit flipped, the flipped bit marked. Two-bit headers that arrive as 00 or 11 could have been sent as either. Flips of 1100, USB’s control header, read back as control the same way.

**The numbers**

*Every single-bit flip of USB’s two 128b/132b headers.*

| Received | Sent | Bits from 0011 | Bits from 1100 | Read as |
|---|---|---|---|---|
| 1011 | 0011 | 1 | 3 | Data |
| 0111 | 0011 | 1 | 3 | Data |
| 0001 | 0011 | 1 | 3 | Data |
| 0010 | 0011 | 1 | 3 | Data |
| 0100 | 1100 | 3 | 1 | Control |
| 1000 | 1100 | 3 | 1 | Control |
| 1110 | 1100 | 3 | 1 | Control |
| 1101 | 1100 | 3 | 1 | Control |

128b/132b

### Four header bits that fix their own errors

**Field marks.** USB’s header is 0011 for data and 1100 for control, and the two differ in every bit. Flip any one bit and the header is still one bit from what was sent and three from the other, so the receiver corrects it and reports the error.

**Look-alike.** 128b/130b, PCIe’s code. Its 2-bit header, like 64b/66b’s, has only two valid patterns. One flip makes a pattern that is neither, so the receiver knows the block is bad but not what it was.

**Range.** 4 bits of every 132, 3.03%, the same share as 64b/66b. 128b/130b spends 1.54%.

**Habitat.** USB 3.1 Gen 2 and USB 3.2 at 10 Gb/s a lane, from 2013. DisplayPort 2.0’s UHBR rates from 2019, and USB4 at 20 Gb/s with its error correction off. USB4’s headers are 0101 and 1010, also four bits apart.

## Four levels need error correction

*PCIe 6.0 and 400G Ethernet*

PCIe 6.0 at 64 GT/s and 400G Ethernet send two bits per symbol on four levels, PAM4. At the same swing each of its three [eyes](https://nearfieldnotes.com/glossary/#g-eye-diagram) is at best a third as tall as one two-level eye, so raw errors become common and error correction moves into the link.

PCIe 6.0 drops the block code. It sends fixed 256-byte flits. Each holds 236 bytes of packets, 6 of link data, 8 of CRC and 6 of error correction, so 7.8% carries no packet data. [Note 28](https://nearfieldnotes.com/notes/crc/) shows how that CRC is built. 400G Ethernet recodes 64b/66b as 256b/257b and adds Reed-Solomon RS(544,514), 5.9% of the line in all.

**Fig. 26k: Two levels and four.**

![Fig. 26k: Two levels and four](https://nearfieldnotes.com/notes/line-codes/fig-26k.png)

*What the figure shows:* Figure 26k: eye diagrams of NRZ, two levels, and PAM4, four levels, at the same swing and symbol rate through the same channel and noise. The NRZ eye is open 78% of the swing at its middle. PAM4's three eyes are open 15%, 15%, 16%.

The same swing, symbol rate and noise through the same channel, a two-pole low-pass at 0.75 times the symbol rate. The channel shows the effect and models no real link. Darker is where the signal passes more often. Openings are measured at each eye’s middle.

**The numbers**

*Same swing, symbol rate and noise. The channel is a two-pole low-pass at 0.75 times the symbol rate.*

| Signal | Levels | Bits a symbol | Eye open at the middle, share of the swing |
|---|---|---|---|
| NRZ | 2 | 1 | 78% |
| PAM4 | 4 | 2 | 15% / 15% / 16% |

PAM4

### Two bits a symbol, a third of the eye

**Field marks.** Four levels, so each symbol carries two bits and the line needs half the symbol rate NRZ would. Through this channel the NRZ eye stays 78% open and each PAM4 eye about 15%.

**Look-alike.** Error correction in place of any line code. PCIe 6.0 calls its scheme 1b/1b, meaning no block code, but it still scrambles its bits and Gray-codes each pair onto the four levels.

**Range.** PCIe 6.0’s flit spends 7.8% on link data, CRC and correction, and 400G Ethernet spends 5.9%. Both cost more than 128b/130b’s 1.54%.

**Habitat.** 400G Ethernet from 2017 and PCIe 6.0 from 2022. USB4 version 2.0 uses three levels instead, packing 11 bits into 7 three-level symbols: 3⁷ = 2,187 patterns for 2¹¹ = 2,048 values.

## Which links use which code

*From each standard’s own documents*

Each code’s share counts the line bits that carry no data. Every row links the spec, standards body or vendor it comes from. [Note 14](https://nearfieldnotes.com/notes/phy-link/) places these codes inside each link’s [PHY](https://nearfieldnotes.com/glossary/#g-phy).

## Reading a link’s line code

*From its levels and its rates*

A link’s line rate over its data rate gives its code away, along with a few other marks. The key sorts them.

Key to line codes

### Which line code is your link using?

1. 1a The line has two voltage levels Go to 2
2. 1b Three or four Scrambled, with error correction
3. 2a 10 line bits for every 8 data bits Go to 3
4. 2b Fewer Go to 4
5. 3a A clock runs on its own pair TMDS: DVI and HDMI up to 2.0
6. 3b No clock pair 8b/10b
7. 4a 18 for every 16 16b/18b: HDMI 2.1
8. 4b Fewer Go to 5
9. 5a 130 for every 128 128b/130b: PCIe 3.0 to 5.0
10. 5b 66 for every 64 Go to 6
11. 6a A USB 3.2 link at 10 Gb/s a lane, DisplayPort 2.x, or USB4 at 20 Gb/s with error correction off 128b/132b
12. 6b Ethernet, Fibre Channel, InfiniBand, or USB4 at 10 Gb/s with error correction off 64b/66b

At 1b: PCIe 6.0’s flits, 400G Ethernet’s 256b/257b with Reed-Solomon, and USB4 version 2.0’s 11 bits in 7 symbols. Line rate over data rate: 8b/10b 1.25, 16b/18b 1.125, 128b/130b 1.016, and 1.031 for both 64b/66b and 128b/132b. Ethernet and Fibre Channel links that recode 64b/66b as 256b/257b with Reed-Solomon keep 64b/66b’s line rate, so they end at 6b too.

## Send a block yourself

*Four codes, three blocks, one lane*

Pick a code and a block. Each pair is its own run through the lane of Fig. 26b, with the first 48 bits it puts on the line above.

Plain bits do fine on random bytes, which is why a scrambler alone works on ordinary traffic. The block built to match SONET’s scrambler is the case RFC 2615 recorded.

**Note 26’s explorer: One lane, one block.**

![Note 26’s explorer: One lane, one block](https://nearfieldnotes.com/notes/line-codes/fig-explore.png)

*What the figure shows:* Every combination of code and block through the same SATA lane: the first 48 line bits of the block, and the receiver's voltage over time.

Receiver voltage from 0.4 µs before the block, as in the opening figure, with the block bracketed. SONET’s scrambler runs alone, without SONET’s frame overhead, and starts over at the block as at a frame’s start. The closest a bit comes to 0 V is the smallest voltage at any bit’s middle, before, in or after the block.

**The numbers**

*Every code and block through the same lane, 0.4 µs before the block to 7.3 µs after its start.*

| Code | Block | Longest run | Closest a bit comes to 0 V | 4 KB takes | Not data |
|---|---|---|---|---|---|
| Plain bits | Zeros | 32,768 bits | 2.7 mV | 5.46 µs | 0% |
| Plain bits | Random | 16 bits | 246 mV | 5.46 µs | 0% |
| Plain bits | Built to match SONET | 7 bits | 247 mV | 5.46 µs | 0% |
| 8b/10b | Zeros | 3 bits | 250 mV | 6.83 µs | 20% |
| 8b/10b | Random | 5 bits | 250 mV | 6.83 µs | 20% |
| 8b/10b | Built to match SONET | 4 bits | 250 mV | 6.83 µs | 20% |
| 64b/66b | Zeros | 17 bits | 246 mV | 5.63 µs | 3.03% |
| 64b/66b | Random | 16 bits | 246 mV | 5.63 µs | 3.03% |
| 64b/66b | Built to match SONET | 13 bits | 247 mV | 5.63 µs | 3.03% |
| SONET’s scrambler alone | Zeros | 7 bits | 246 mV | 5.46 µs | 0% |
| SONET’s scrambler alone | Random | 18 bits | 244 mV | 5.46 µs | 0% |
| SONET’s scrambler alone | Built to match SONET | 32,768 bits | 2.7 mV | 5.46 µs | 0% |

#### Conditions

- **Lane:** One SATA pair. 0.25 V on each wire, opposite ways, behind 50 Ω. 12 nF in series. 50 Ω to ground at the receiver. ±250 mV at the receiver. No cable or traces.
- **Bits:** 6 Gb/s with 40 ps edges, the caps uncharged at the start. Each run sends 300 random bytes, the 4 KB block, then random bytes past 7.3 µs.
- **Codes:** 8b/10b from its published tables, running disparity carried through. 64b/66b with the 1 + x³⁹ + x⁵⁸ scrambler and its headers. SONET’s 1 + x⁶ + x⁷ scrambler from 1111111. Plain bits are a what-if: SATA scrambles its data before 8b/10b.
- **Eyes:** NRZ and Gray-coded PAM4 with the same outer levels and symbol rate, through a two-pole low-pass at 0.75 times the symbol rate, with Gaussian noise of 0.035 where the outer levels are ±1.
- **Renders:** Blender, one camera angle for the drive and its close-up.
- **Solver:** ngspice: 12 runs of the lane, one for each code and block.

Simulated only. Nothing on this page has been measured on a board yet.

#### Limits

- The lane has no cable. A real channel adds loss and reflections that close the eye further.
- The receiver is ideal: no noise, no offset and no clock recovery. The page counts edges and margins, not errors.
- The 12 nF and 500 mV come from SATA 1.0a, written for 1.5 Gb/s. Later revisions set their own limits for 6 Gb/s.
- The eyes’ channel is illustrative. Real PAM4 links equalize, and their eyes differ.
- 128b/130b’s header is reasoned from its two valid patterns, not simulated.
- SONET’s frame overhead isn’t modeled. On a real link its overhead bytes sit between rows of payload and break a long run.

#### Files

- sim/site.py Every code and block through the lane, for the opening figure, Fig. 26c and the explorer
- sim/wander.py The lane, and the zero blocks the video uses
- sim/coding.py 8b/10b, 64b/66b, SONET’s scrambler and USB’s headers
- sim/codes.py The comma stream, the 64b/66b blocks, the SONET packets, the header flips and the eyes
- render/ssd.py The drive, its caps and its plug in Fig. 26

#### Sources

- [Serial ATA 1.0a, the 12 nF, the 500 mV, the plug, K28.5 and scrambling](https://web.mit.edu/fustflum/etcetera/serialata10a.pdf)
- [SATA-IO, “SATA 6Gb/s: Fast Just Got Faster”, 2009](https://www.sata-io.org/sites/default/files/documents/SATA-6Gbs-Fast-Just-Got-Faster_1.pdf)
- [Widmer and Franaszek, Electronics Letters, 1983, IBM’s record](https://research.ibm.com/publications/transmission-code-for-high-speed-fibre-optic-data-networks)
- [US 4,486,739, the code’s run length and balance](https://patents.google.com/patent/US4486739A/en)
- [IEEE 802.3-2008 Section 4, 10GBASE-R and SONET’s scrambler length](https://cdn.shopify.com/s/files/1/0790/5963/files/IEEE_802.3-2008_Section_4.pdf)
- [IEEE 802.3ae task force, 2002](https://www.ieee802.org/3/ae/)
- [IEEE 802.3ba task force, 40 and 100G Ethernet, 2010](https://www.ieee802.org/3/ba/)
- [IEEE 802.3 reflector, the longest possible run](https://ieee802.org/3/10G_study/email/msg03968.html)
- [10GEA, XAUI](https://www.10gea.org/whitepapers/xaui-interface)
- [US 5,163,092, SONET’s 1 + x⁶ + x⁷ scrambler](https://patents.google.com/patent/US5163092A/en)
- [RFC 2615, PPP over SONET/SDH](https://www.rfc-editor.org/rfc/rfc2615.txt)
- [PCI-SIG, PCIe 3.0 FAQ, archived](https://web.archive.org/web/20130119111903/http://www.pcisig.com/news_room/faqs/pcie3.0_faq/)
- [PCI-SIG, PCIe 3.0 release, 2010](https://us.design-reuse.com/news/24978/pci-express-3-0-specification.html)
- [Intel, PCIe 3.0 features and the 8 GT/s choice, 2011](https://downloads.openfabrics.org/downloads/Media/Monterey_2011/Apr5_pcie%20gen3.pdf)
- [Intel, PIPE specification 7.1, the PHY interface and its sync headers](https://cdrdv2-public.intel.com/643108/643108_PIPE_Arch_Spec_Rev_7_1.pdf)
- [USB 3.2 specification, its codes and headers](https://usb.org/sites/default/files/usb_32_202206_1.zip)
- [USB 3.1 release, 2013](https://www.design-reuse.com/news/32551/superspeed-usb-10-gbps.html)
- [USB4 specification 2.0, its block headers](https://www.usb.org/sites/default/files/USB4%20Specification%20November%202025.zip)
- [Synopsys, three levels in USB’s version 2.0](https://www.synopsys.com/designware-ip/technical-bulletin/pam3-technology-implementation-usb4-v2.html)
- [PCI-SIG, PCIe 6.0’s flit](https://pcisig.com/blog/evolution-pci-express-specification-its-sixth-generation-third-decade-and-still-going-strong)
- [PCI-SIG at SNIA SDC 2021, PCIe 6.0’s Gray coding](https://snia.org/sites/default/files/2025-05/SNIA-SDC21-Mazumder-PCIe6p0-A-High-Performance-Interconnect-for-Storage-Networking-Challenges.pdf)
- [Cadence, PCIe 6.0’s scrambling and precoding](https://community.cadence.com/cadence_blogs_8/b/fv/posts/introduction-of-precoding-in-pcie-6-0)
- [IEEE 802.3bs, 256b/257b and RS(544,514)](https://www.ieee802.org/3/bs/public/15_03/gustlin_3bs_02a_0315.pdf)
- [IEEE 802.3bj, recoding for 100 Gb/s at the same line rate](https://www.ieee802.org/3/bj/public/nov11/cideciyan_01a_1111.pdf)
- [VESA, DisplayPort overview](https://www.vesa.org/wp-content/uploads/2011/01/ICCE-Presentation-on-VESA-DisplayPort.pdf) and [DisplayPort 2.0](https://vesa.org/press/vesa-publishes-displayport-2-0-video-standard-enabling-support-for-beyond-8k-resolutions-higher-refresh-rates-for-4k-hdr-and-virtual-reality-applications/)
- [HDMI Forum, HDMI 2.1](https://www.hdmi.org/announce/detail/172) and [Keysight on its 16b/18b](https://www.keysight.com/gb/en/assets/3123-1374/data-sheets/HDMI-Electrical-Compliance-Test-Adapters.pdf)
- [DVI 1.0, TMDS](https://www.fpga4fun.com/files/dvi_spec-V1_0.pdf)
- [FCIA speedmap](https://fibrechannel.org/wp-content/uploads/2015/10/FCIA_SPEEDMAP_v21.pdf) and [Mellanox, FDR InfiniBand](https://network.nvidia.com/pdf/whitepapers/WP_FDR_InfiniBand_is_Here.pdf)
- [ngspice, the circuit simulator](https://ngspice.sourceforge.io/)

What should the next note be? [Ask for one](https://nearfieldnotes.com/#ask-for-a-note)

---

Source: https://nearfieldnotes.com/notes/line-codes/

Cite as: Michael Walker, “Line codes”, Near Field Notes, Note 26, Rev 1, 8 Nov 2026. https://nearfieldnotes.com/notes/line-codes/

Figures: free to reuse under CC BY 4.0 (https://nearfieldnotes.com/license/). Each one's image is linked under its name. Credit Michael Walker, Near Field Notes, and link the figure: this address plus #fig- and its number, like https://nearfieldnotes.com/notes/line-codes/#fig-26.