Note 28Signal integrity Rev 1 Watch the video · 3:14

CRCs on fast links

How does a CRC catch bad bits, and what do fast links do when it fails?

It divides the frame by a fixed polynomial and sends the remainder, and the receiver’s own division has to land on a known constant. Ethernet’s CRC-32 catches any 3 flipped bits in a full 1518-byte frame, and any burst up to 32 bits long. Ethernet drops a bad frame, PCIe and DDR memory send it again, and a cut-through switch that has already sent most of it stomps its CRC so the next box knows.

In the figure one bit flips at byte 700 on the way into a switch. The switch is sending the frame on before it has all arrived, so when the check fails at the end it marks the frame dead instead.

A bad frame, stomped

One flipped bit through a cut-through switch

A 1518-byte Ethernet frame to scale: a 14-byte header in gray, data in blue, the 4-byte FCS at the end. The red tick is the flipped bit. Bytes are written in the order they go on the wire. The out port is drawn 14 bytes behind, once the header is in.

The numbers

Bytes in the order they go on the wire.
	Value
Frame	1518 bytes: 14 of header, 1500 of data, 4 of FCS
Flipped on the way in	Byte 700, bit 3
FCS sent	87 CB 59 48
CRC of what arrived	AE D4 DF 4D
FCS written out	51 2B 20 B2, the inverse of AE D4 DF 4D
The next box	Its CRC of the frame is the inverse of the FCS: stomped

The frame check sequence

Four bytes on every Ethernet frame

A switch like this one takes frames in on one port and sends them out another. The chip under the big heatsink reads each frame’s header to pick the port, and checks its last four bytes on the way through.

At 100 Gb/s a port carries more than 8 million full frames a second. Every one ends in the same kind of check, and every port of every box along the path runs it again.

A 32-port switch, cover off

A 1U switch with 32 QSFP28 ports, its chassis sized from the Edgecore AS7712-32X datasheet and its board laid out for the picture. The lit lanes carry the opening figure’s frame from port 5 to the switch chip and back out to port 27.

The numbers

Part	Value
Ports	32 QSFP28, 100 Gb/s each
In	Port 5
Out	Port 27
Size	438.4 × 515.0 × 43.5 mm, the Edgecore AS7712-32X’s
Board	Schematic: placed for the picture

Those four bytes are the frame check sequence, the FCS. The sender runs a CRC over everything from the destination address to the last data byte and puts the result at the end.

The receiver runs the same CRC over the same bytes. If its answer doesn’t match, at least one bit changed on the way.

An Ethernet frame

The opening figure’s frame, sent to every port from a locally assigned address. Its 1500 data bytes are random. The preamble lets the receiver lock on and sits outside the CRC.

The numbers

The opening figure’s frame, bytes in wire order.
Field	Bytes	This frame	Covered by the CRC
Preamble and start delimiter	8	—	No
Destination	6	FF FF FF FF FF FF	Yes
Source	6	02 00 00 00 A1 B2	Yes
Type	2	08 00	Yes
Data	46 to 1500	67 FE …	Yes
FCS	4	87 CB 59 48	Is the CRC

Division with XOR

A 4-bit CRC by hand

A CRC treats the message as one long binary number and divides it by a fixed divisor, the generator polynomial. The CRC is the remainder.

This page writes a polynomial as its coefficient bits, highest power first, so 10011 is x⁴ + x + 1. Subtraction is XOR, with no borrows. The sender adds as many zeros as the CRC has bits and divides:

R(x)=M(x)·xⁿmodG(x)

=110101100000mod10011=0110

The sender sends 11010110 0110, the message with its remainder. Divide that by 10011 and the remainder is 0000, so a receiver can check by dividing everything it got.

Long division by 10011

Each row XORs the divisor under the leading 1. Gray bits are already zero. The last four bits are the remainder.

The numbers

Coefficient bits, highest power first.
Step	Bits
Message and 4 zeros	110101100000
XOR 10011 at bit 0	010011100000
XOR 10011 at bit 1	000000100000
XOR 10011 at bit 6	000000000110
Remainder	0110

The register that divides

One bit a clock

Hardware does the same division with a shift register and two XOR gates. Each clock one message bit goes in.

The bit falling out of r3 is XORed with the bit coming in. If the result is 1, it XORs the divisor into the register as everything shifts left. That is one step of the long division.

After the eighth bit the register holds 0110, the same remainder as Fig. 28c, and this form of the register needs no zeros added.

The register, clock by clock

The message of Fig. 28c, first bit first, into a 4-bit register dividing by 10011. Arrows show where each bit moves on the clock. It rests on clock 8.

The numbers

Clock	Bit in	Feedback	r3 r2 r1 r0
0	—	—	0000
1	1	1	0011
2	1	1	0101
3	0	0	1010
4	1	0	0100
5	0	0	1000
6	1	0	0000
7	1	1	0011
8	0	0	0110

Ethernet’s 32-bit register

04C11DB7

Ethernet’s divisor has 33 bits, from x³² down to 1. Written in hex with its top bit left off, as specs usually write it, it is 04C11DB7. Its register has 32 cells and 14 taps.

The register starts at all ones, and the sender flips the CRC’s bits before sending it. Because of those two choices, a receiver that runs the whole frame and its FCS through the register doesn’t land on zero.

It lands on C704DD7B for every good frame of every length. One flipped bit in the 1518-byte frame and it ends on 1AF71290 instead.

Where the register ends

The receiver’s register after each frame and its FCS have gone through, bits in the order they’re sent. A 1 is filled, a 0 left empty, r31 at the left. Each triangle marks a cell the feedback is XORed into. Red frames mark the cells that differ from a good frame’s.

The numbers

Bits go in the order they're sent.
Run	Register at the end	r31 … r0
Starts at	FFFFFFFF	11111111111111111111111111111111
64-byte frame and its FCS	C704DD7B	11000111000001001101110101111011
590-byte frame and its FCS	C704DD7B	11000111000001001101110101111011
The opening figure’s 1518-byte frame	C704DD7B	11000111000001001101110101111011
The same frame, 1 bit flipped	1AF71290	00011010111101110001001010010000

What it always catches

By frame length

Any error is itself a pattern of flipped bits. The CRC misses it only if that pattern divides by the polynomial exactly, and a polynomial can be chosen so that no pattern of a few bits does.

For Ethernet’s, the guarantee depends on length. Any 4 flipped bits are caught in frames up to 375 bytes, and any 3 up to 11,454 bytes, which covers full frames and 9018-byte jumbo frames. Any burst up to 32 bits long is caught at every length.

Past the guarantee, a few patterns slip through. In a full frame they are a tiny share of all 4-bit errors:

P=W₄N(N− 1)(N− 2)(N− 3) ÷ 24

=223,059905,776,814,103,876=1 in 4.06 billionfor N = 12,144

What CRC-32 always catches

The largest number of flipped bits Ethernet’s CRC-32 catches every time, against frame length with its FCS, on a log scale. Each step ends at the length printed under it. Koopman’s breakpoints; the steps from 2 to 5 bits were checked here by search.

The numbers

Koopman’s breakpoints for 04C11DB7, from data bits to bytes with the 4-byte FCS.
Flipped bits always caught	Frame length with FCS, bytes	Ethernet frames in that range
6	Up to 25	None: the smallest is 64 bytes
5	26 to 37	None
4	38 to 375	64 bytes up to 375
3	376 to 11,454	1518-byte frames and 9018-byte jumbos
2	11,455 and longer	None

One polynomial, five CRC-32s

Hammond, Brown and Liu, 1975

The polynomial alone doesn’t pin a CRC down. The start value, the bit order and the final flip all change the answer, and each mix has its own name. Two tools that both say CRC-32 can disagree on every file.

Five CRC-32s of the same input

Each computed here and checked against the check values in RevEng’s catalog. LSB first means each byte goes in lowest bit first, as Ethernet sends it.

The numbers

Name in RevEng’s catalog	Start	Bit order	Final flip	CRC-32 of “123456789”
ISO-HDLC: zip, Ethernet	FFFFFFFF	LSB first	Yes	CBF43926
BZIP2	FFFFFFFF	MSB first	Yes	FC891918
MPEG-2	FFFFFFFF	MSB first	No	0376E6E7
CKSUM	00000000	MSB first	Yes	765E7680
JAMCRC	FFFFFFFF	LSB first	No	340BC6D9

536

CRC-32

The Ethernet polynomial

Field marks. Polynomial 04C11DB7, start FFFFFFFF, bytes in lowest bit first, final flip. The CRC of “123456789” is CBF43926. A receiver’s register ends on C704DD7B after a good frame. RevEng’s catalog lists it bit-reversed, as DEBB20E3.

Look-alike. CRC-32C, polynomial 1EDC6F41, in iSCSI and NVMe over TCP. It catches every odd number of flipped bits at any length. In a full frame it also catches any 3, and it misses 312,496 4-bit patterns where Ethernet’s misses 223,059.

Range. Any 3 flipped bits up to 11,454 bytes, any 2 out to 512 MiB, any burst up to 32 bits at any length.

Habitat. Ethernet since the 1980 DIX spec. PCIe’s LCRC and ECRC, USB 3’s data, SAS, and SATA, which starts it from 52325032. Hammond, Brown and Liu recommended it in a 1975 study for the US Air Force, and the DIX spec notes the same polynomial in AUTODIN II, a US military network.

537

When the check fails

From each standard’s own documents

Every link below checks a CRC. They split on what happens next. Ethernet throws the frame away and leaves the resending to TCP. Short links that can’t lose data, like PCIe, SATA and memory, ask for it again on the spot. Every row links the spec, standards body or vendor it comes from. Note 14 shows where the check sits above each link’s PHY.

Ethernet, every speedCRC-32 FCS, 04C11DB7The frame, destination to data

The port drops it, and TCP sends again what isn’t acknowledged. A cut-through switch that has already sent most of it stomps its FCS.

AMD PG051, the FCS DIX Ethernet 1.0, 1980 Cisco, CRC errors Cisco, stomped CRCs RFC 9293, TCP

PCIe 1.0 to 5.0 packetsLCRC, 32 bits, 04C11DB7The packet and its 12-bit sequence number

A NAK, and the sender replays from its retry buffer. After the 4th failed replay the link retrains.

PCIe Base 2.0 PLX PEX 8604

PCIe link packetsCRC-16, 100BThe 6-byte DLLP

Discarded, and counted as a Bad DLLP error.

PCIe Base 2.0

PCIe end to endECRC, 32 bits, optionalHeader and data, end to end

The far end reports it and discards the packet. Switches pass the ECRC on unchanged.

PCIe Base 2.0 PLX PEX 8604

PCIe 6.0 flits8 bytes, built on Reed-Solomon242 of the flit’s 256 bytes

Checked after the FEC. A NAK, and the flit is sent again.

PCI-SIG, PCIe 6.0 Synopsys, FEC then CRC

USB 2.0CRC-5 tokens, CRC-16 dataA token’s fields, or the data

Ignored, with no handshake. The host tries up to 3 times.

USB 2.0 spec

USB 3.xCRC-16 header, 100B; CRC-32 data, 04C11DB7The 12-byte header; up to 1024 bytes of data

A bad header gets LBAD and is resent hop by hop. Bad data gets an ACK asking for a retry, end to end.

USB 3.2 spec

SATACRC-32, 04C11DB7, starting from 52325032Each frame, a FIS

R_ERR. A register FIS may be sent again. A data FIS should never be.

Serial ATA 1.0a

DDR4 and DDR5 memoryCRC-8, x⁸ + x² + x + 1, on DDR4 writes72 bits per byte lane per write

The DRAM pulses ALERT_n and the controller writes again. DDR5 checks reads too.

Micron DDR4 Synopsys, DDR5

iSCSI and NVMe/TCPCRC-32C, 1EDC6F41, optionalEach PDU’s header and data, end to end

A bad header can’t be trusted for its length, so the receiver skips ahead or drops the connection. Bad data is rejected and recovered on iSCSI, and fails just that command on NVMe/TCP.

RFC 7143, iSCSI NVMe/TCP 1.1

Errors inside the boxes

End to end

A link CRC covers one hop. Each switch checks the frame, holds it in memory, and computes a fresh FCS on the way out. A bit that flips inside the switch, after the check and before the new FCS, leaves with a valid CRC.

Stone and Partridge watched real traffic in 2000. Between 1 packet in 1,100 and 1 in 32,000 failed TCP’s checksum, on links whose CRCs should have missed about 1 error in 4 billion. The errors came from sources a link CRC can’t see, from memory errors to software bugs.

That is why PCIe has an optional end-to-end ECRC that switches pass on unchanged, and why iSCSI and NVMe over TCP put CRC-32C digests on their data.

Four levels, routine retries

PCIe 6.0, 2022

PCIe 6.0 runs four voltage levels at 64 GT/s. Its eyes shrink, and bit errors stop being rare. It sends fixed 256-byte flits with error correction built in, and one 8-byte CRC per flit replaces the CRC on each packet. Note 26 follows the flit from the line code side.

A PCIe 6.0 flit

Bytes to scale. The receiver corrects with the FEC first, then checks the CRC to decide whether to accept the flit.

The numbers

From PCI-SIG’s description of the PCIe 6.0 flit.
Part of the flit	Bytes
Packets	236
Link	6
CRC	8
FEC	6

538

Flit CRC

Eight bytes, checked after correction

Field marks. 8 bytes over the flit’s first 242. It is built from a Reed-Solomon code over bytes and used only to detect. The FEC after it is 6 bytes, three groups of 2, each able to fix one bad byte.

Look-alike. The FEC, which fixes errors where a CRC only finds them. The CRC checks what the FEC leaves, and a flit that fails gets a NAK and is sent again.

Range. Up to 8 bad bytes after correction are always caught, and a worse flit slips through with a chance of 2⁻⁶⁴. At PCI-SIG’s design error rate, about 5 flits in a million are retried.

Habitat. PCIe 6.0 and 7.0, and CXL 3. CXL’s latency-optimized flit checks a 6-byte CRC on each half first, and runs the FEC only when it fails. Das Sharma, Blankenship and Berger put the CRC at about 10 levels of gates against the FEC’s 50, and the saving at about 2 ns on a x16 link.

539

At link speed

1024 bits a clock

One bit a clock would need a 400 GHz clock for 400G Ethernet. A MAC takes a wide word each clock instead:

f=Dw

=400 Gb/s1024 bits=391 MHz

Intel’s F-tile 400G MAC takes 1024 bits at 415 MHz or more when its error correction is on, a 2.41 ns clock.

Write the register’s next state for a whole word at once and every output bit becomes one big XOR. At 8 bits a clock the busiest bit has 14 inputs. At 1024 it has 554, and only 21 of them come from the register itself.

A 64-byte frame takes 84 bytes of line with its preamble and the gap after it. The smallest frames arrive faster than the clock:

t=(64 + 20) bytes × 8D

=672 bits400 Gb/s=1.68 ns

So one word can hold the end of one frame and the end of the next, and the CRC logic has to finish both in one clock. AMD’s DCMAC is built for up to two frames a clock.

Inputs to one CRC bit

All inputs
From the register

Ethernet’s CRC-32 taking a word of the given width each clock. Each dot is the most inputs any one of the 32 output bits XORs together, on log scales. Lines mark the widths of 10G, 100G and 400G MACs.

The numbers

CRC-32, 04C11DB7, every output bit written out as one XOR.
Bits per clock	Inputs to the busiest bit	From the register	From the data	Two-input XORs, no sharing
1	3	2	1	27
2	5	3	2	54
4	7	4	3	108
8	14	7	7	220
16	20	10	10	414
32	34	17	17	872
64	52	19	34	1,390
128	89	20	69	2,518
256	157	21	138	4,424
512	288	21	271	8,480
1,024	554	21	533	16,744

Which CRC, and what happens

From the link you have

The link sets the CRC, and the CRC’s place in the link sets what a failure does. The key sorts them.

Key to link CRCs

Which CRC does your link use, and what happens when it fails?

1aThe link carries Ethernet framesGo to 2
1bSomething elseGo to 3
2aStorage over TCP: iSCSI or NVMe/TCPFCS plus CRC-32C digests
2bAny other trafficCRC-32 FCS: dropped or stomped
3aDDR4 or DDR5 memoryWrite CRC: written again
3bPCIe, USB or SATAGo to 4
4aPCIeGo to 5
4bUSB or SATAGo to 6
5aIn flit mode, as at 64 GT/sFlit CRC after the FEC: replayed
5bNot in flit mode: PCIe 1.0 to 5.0LCRC each hop: replayed
6aSATACRC-32 from 52325032: R_ERR
6bUSBGo to 7
7aUSB 3, at 5 Gb/s and upCRC-16 and CRC-32: resent
7bUSB 2.0CRC-5 and CRC-16: up to 3 tries

At 2a, bad data is resent on iSCSI and fails its command on NVMe/TCP. At 2b, a stomped FCS is the inverse of the CRC the next box computes, so it counts the frame as damaged upstream. At 5b, the link retrains after the 4th failed replay, and PCIe’s link packets carry a CRC-16 of their own. At 6a, a register FIS may be sent again and a data FIS should never be. At 7a, a bad header is resent hop by hop and bad data is retried end to end.

Corrupt a frame yourself

Six errors, one frame

Pick an error. Each is flipped into the opening figure’s frame as sent, FCS and all, and the whole frame goes through the receiver’s register. A good frame ends on C704DD7B.

The two misses are real. The 4 bits at bytes 393, 610, 1121, 1124 are one of the 223,059 patterns the polynomial divides in a full frame, found by search. The 33-bit burst is the polynomial itself.

Error

One frame, one error

1 bit flipped, at byte 700

Bits flipped: 1
First to last: 1 bit
Register ends on: 1AF71290
Check: Caught

The frame as in the opening figure, each red mark a flipped bit or a run of them, with the byte it falls in. Below, the receiver’s register after the frame, cells that differ from a good frame’s framed in red.

The numbers

Each error flipped into the opening figure’s 1518-byte frame as sent, FCS included, then run through the receiver’s register.
Error	Bits flipped	First to last, bits	Bytes hit	Register at the end	Check
1 bit flipped, at byte 700	1	1	700	1AF71290	Caught
2 bits, 1,300 bytes apart	2	10,406	100, 1400	7850AF05	Caught
3 bits across the frame	3	11,756	30, 700, 1500	3F7C1A8E	Caught
A burst 32 bits long	10	32	900, 901, 902, 903	285CE303	Caught
4 bits the polynomial misses	4	5,855	393, 610, 1121, 1124	C704DD7B	Missed
33 bits that match the polynomial	15	33	1100, 1101, 1102, 1103, 1104	C704DD7B	Missed

Conditions

Frame: 1518 bytes: broadcast destination, source 02 00 00 00 A1 B2, type 08 00, 1500 bytes of seeded random data, then its FCS. One bit flipped at byte 700, bit 3.
CRC-32: Polynomial 04C11DB7 from FFFFFFFF, bytes in lowest bit first, final flip, checked against zlib. The receiver’s register is the shift-left form of Fig. 28d, run over the frame and its FCS in wire order.
Guarantees: Koopman’s breakpoints for 04C11DB7 and CRC-32C, and the count of 4-bit patterns each misses in a full frame, reproduced by search.
Errors: Flipped into the frame as sent. The 4-bit miss was found by searching for powers of x whose sum divides by the polynomial. The 32-bit burst has random bits between its two flipped ends.
Parallel CRC: The register’s next state written out for 1 to 1024 bits a clock, each output bit as one XOR, with no shared terms.
Render: Blender, one camera angle. The switch is generic.

Computed only. No frames were captured from a real link.

Limits

The switch is drawn, not modeled. Real cut-through switches wait for more than the header, and their delay varies.
The guarantees count flipped bits. Real links make bursts, and a descrambler below the CRC turns one line error into several flipped bits.
DDR5’s CRC width isn’t given here. The page gives DDR4’s from Micron and says only that DDR5 adds reads.
The parallel counts assume one XOR per output bit. Synthesis tools share terms and use far fewer gates.
SAS appears only as a user of the polynomial. Its handling of a failed CRC isn’t covered.

Files

sim/crc.pyThe frame, its FCS and its stomp, the CRC-4 division and register, the five CRC-32s and the 400G timing
sim/site.pyThe receiver’s register for good and bad frames, the explorer’s errors and the inputs per CRC bit
refs/checks/crc32_breakpoints.pyKoopman’s breakpoints and 4-bit counts for 04C11DB7 and CRC-32C
refs/checks/parallel_crc_matrix.pyThe parallel CRC equations at each word width
render/switch.pyThe switch with its cover off in Fig. 28

Sources

Like this note?

Rev 1 · 9 Nov 2026

Rev 19 Nov 2026First published

Each fix gets a line here, with the reader's name if they want credit.

Did it answer your question?

Want more on this?

Report a problem

What should the next note be? Ask for one