PCI Express 6.0

x16, PER DIRECTION (payload, post 242B/256B flit framing). AUDIT 2026-10-05: THE STORED VALUE WAS WRONG AND HAS BEEN CORRECTED. It previously read 236.0, on the reasoning that PCI-SIG's 256.0 GB/s at x16 was 'the UNENCODED PER-DIRECTION rate'. That reading is refuted by PCI-SIG's own direction word. THE CONVENTION, AND WHY 236 WAS WRONG: PCIe figures are quoted PER LANE PER DIRECTION, and a PCIe lane is dual-simplex (independent TX and RX conductor pairs), so a per-direction figure is ALREADY complete for its direction and must never be halved again - nor, in the other direction, doubled by treating an aggregate as per-direction. PCI-SIG (w7p-pcisig-pcie6-faq), verbatim, from the question 'Why does PCIe 6.0 specification utilize PAM4 signaling over NRZ signaling?': 'The utilization of PAM4 allows the PCIe 6.0 specification to reach 64.0 GT/s data rate and up to 256.0 GB/s BIDIRECTIONAL bandwidth via a x16 configuration.' The word BIDIRECTIONAL is PCI-SIG's own, and the arithmetic closes on that reading: 16 lanes x 64 GT/s / 8 = 128.0 GB/s per direction, x2 for both directions = 256.0. THE 236 VALUE ALSO FAILS AN INDEPENDENT CHECK, which is why it is recorded as wrong rather than merely contested: 236 was derived as if the flit framing were 236B/256B, but PCI-SIG's flit is a 256-BYTE structure ('PCI-SIG adopted a 256-Byte Flit structure', w7p-pcisig-pcie6-faq) carrying 242 bytes of payload (w7p-wikipedia-pcie-link-performance), giving 242/256 = 94.53%. At 242/256 the per-direction payload at x16 is exactly 121.0 GB/s, and that figure is independently corroborated by the secondary table's row '6.0 | 2022 (first implemented 2025) | PAM-4, FEC | 1b/1b, 242B/256B FLIT | 64.0 GT/s | 7.563 | 15.125 | 30.25 | 60.5 | 121' whose x16 column reads 121, with the column footnote 'In each direction (each lane is a dual simplex channel).' A 236 payload is unreachable from 256-byte flits. FULL ARITHMETIC: 64 GT/s x 242/256 = 60.5 Gb/s payload per lane per direction; / 8 = 7.5625 GB/s per lane per direction; x16 = 121.0 GB/s PER DIRECTION. THE THREE FIGURES FOR THIS GENERATION, kept distinct because conflating them is this family's recurring failure: 128.0 GB/s = raw per direction (PCI-SIG's 256.0 bidirectional / 2); 121.0 GB/s = PAYLOAD per direction (this stored value); 242.0 GB/s = payload bidirectional aggregate (121 x 2). Note that the payload bidirectional aggregate (242.0) is numerically equal to PCIe 7.0's per-direction payload (pcie-gen7) - a collision worth knowing about before reading either number out of context.

Point-to-point host-to-device, up to 16 lanes, with flit-level framing and signalling changes versus PCIe 5.0. Shares the physical layer with CXL 4.0. PCI-SIG publishes link widths of 1, 2, 4, 8, 12, 16 and 32 (w7p-pcisig-pcie5-faq-verified); x16 is used here for comparability, not as the maximum.

Optional PCIe switch fabric, as for PCIe 5.0 - store-and-forward, no in-network compute.

WHY BANDWIDTH JUMPS NON-LINEARLY VERSUS GT/s FROM THIS GENERATION ON - the point a GT/s-ONLY COMPARISON GETS WRONG. PCIe 5.0 -> PCIe 6.0 doubles the GT/s rate (32 -> 64) and doubles PCI-SIG's raw bidirectional headline with it (128 -> 256 GB/s), but payload per direction goes 63.0 -> 121.0 GB/s, a ratio of 1.92x, NOT 2x. The missing ~4% is the encoding change: PCIe 1.0-5.0 are NRZ with 128b/130b line coding (98.46% efficient), while PCIe 6.0 and 7.0 are PAM4 with 242B/256B flit framing (94.53%). PCI-SIG, verbatim: 'NRZ uses two levels of signaling, while PAM4 uses four levels. It packs two bits of information into the same amount of time on a serial channel' (w7p-pcisig-pcie6-faq). A reader comparing Gen5 to Gen6 by GT/s alone concludes 'exactly double', then finds 1.92x in the payload and assumes a record is wrong; both are right and the framing overhead is the whole discrepancy. Note the corollary: Gen6 -> Gen7 IS exactly 2.00x on payload per direction (121.0 -> 242.0) because the framing is unchanged between them, so PAM4 makes the FIRST post-NRZ step non-linear and later steps linear again. Any table of this family showing a uniform 2x per generation is either quoting raw rates or has mixed conventions. THE ENCODING IS THE DEPLOYMENT RISK, not just an arithmetic footnote: PAM4 at 64 GT/s raises the bit error rate several orders of magnitude, PCI-SIG verbatim - 'the bit error rate (BER) was several orders of magnitude higher than the 10-12 BER in all prior generations' and 'Flit Mode supports the higher BER expected in PAM4 (10-6 vs 10-12 in NRZ)' - which is why Flit Mode was introduced at all: 'PCI-SIG adopted a 256-Byte Flit structure ... This is a necessary change due to the move to PAM4 encoding and Forward Error Correction (FEC), which only works on fixed-size data packets.' So Gen6 is a materially different signal-integrity, retimer and test problem from Gen5, and PCI-SIG's stated product timeline was '12-18 months after the release of the final specification'. INFERENCE CONSEQUENCE: at 121.0 GB/s per direction x16, a PCIe 6.0 host link is roughly 1.9x the per-direction rate of PCIe 5.0 but still about 3.7x BELOW NVLink 4's 450 GB/s per direction (pcie-gen4, pcie-gen5 carry those figures), so it narrows but does not close the gap to a switch-based scale-up domain - a tensor-parallel plan sized on PCIe 6.0 is still fabric-bound relative to NVSwitch. Revision currency: PCI Express Base Specification Revisions 7.1 and 6.5 are both dated 2026-09-17 on the PCI-SIG index (link-pcisig-specifications), so PCIe 6.0 is a shipped generation, not a preview. Confidence raised from 0.8 to 0.9: the figure now reconciles against PCI-SIG's explicit direction word, against a 256-byte flit whose payload efficiency is independently published, and against a clean generational ladder - the residual uncertainty is only the raw-vs-payload framing distinction, which is now stated rather than buried. DIRECTION AUDIT TRAIL, kept because this is the record the repo corrupted most often: this value has now been 242, then 236, then 121. All three were attempts to reconcile PCI-SIG's 256.0 GB/s against the per-direction convention, and 242 and 236 both failed in the same direction - treating the BIDIRECTIONAL headline as per-direction, which overstates the interconnect by 2x. The resolution is that PCI-SIG prints the direction word itself, so there is nothing to infer. === 121.0 RE-VERIFIED 2026-10-08 (w8-reverify) — CONFIRMED AS THE PER-DIRECTION FIGURE, WITH ONE ~2% RATIO AMBIGUITY LEFT OPEN RATHER THAN SMOOTHED OVER. === The 2x correction 236.0 -> 121.0 was re-derived independently from PCI-SIG's own published numbers, and it is RIGHT. Live PCI-SIG PCIe 6.0 FAQ, verbatim: 'supports a data rate of 64.0 GT/s and up to 256.0 GB/s via a x16 configuration' and, from the PAM4 question, 'up to 256.0 GB/s BIDIRECTIONAL bandwidth via a x16 configuration'. 16 lanes x 64 GT/s / 8 = 128.0 GB/s per direction, x2 = 256.0 bidirectional - the arithmetic closes exactly on PCI-SIG's own direction word with no factor of two, which confirms 236.0 was the aggregate mishandled and 121.0 is of the right size for the quantity. A second independent confirmation of the DIRECTION, not the framing: the sibling PCIe 5.0 FAQ writes its ladder as 'Gigabits/second/Lane/DIRECTION' and gives the worked example '32 Lanes ... 128.0 Gigabytes/second in each direction SIMULTANEOUSLY', so per-lane rates are per direction by construction across this family. WHAT IS LEFT GENUINELY UNRESOLVED, stated because the record previously presented 121.0 as fully settled: the PAYLOAD RATIO. The 121.0 rests on 242/256 = 0.945, which comes from the Wikipedia secondary table this record cites. PCI-SIG's own FLIT blog, read live during the same pass, states the structure differently: 'we settled on 256 Bytes with 236 bytes of TLP payload and a TLP efficiency of 92%'. On PCI-SIG's figures the per-lane payload would be 64 x 236/256 / 8 = 7.40625 GB/s and the x16 per-direction figure 118.5 GB/s, not 121.0. So the ratio is 242/256 per the secondary table or 236/256 per the primary source, and the two differ by ~2%. This record keeps 121.0 because it is the figure both cited sources print in the same units and the same direction, and because every source that publishes a usable Gen6 number agrees it is ~118-121 - but the confidence on the FRAMING is not 0.9 and the ambiguity is recorded in gotcha w8r-cxl-family-broke-the-pcie-direction-convention-it-copied-from rather than hidden in the basis prose. Any reader re-deriving this should expect to hit two candidate ratios and should know the repo has seen both. A related correction to this record's own text: the basis says the old 236.0 value was 'derived as if the flit framing were 236B/256B', which implies 236B is a ratio. PCI-SIG's actual words make 236 a BYTE COUNT of the TLP-carrying region of a 256-byte FLIT, not a ratio, and 242/256 appears on neither PCI-SIG page. The 236.0 error was an aggregate-direction error, not a framing-ratio error.