Link Basics
What the PIPE Interface Is, and What It Is Not
PIPE is the reason a controller core and a PHY from two different suppliers can be wired together at all. It is an interface specification, not a protocol layer.
The name, and the document behind it
PIPE is the short name for a specification whose full title is longer than most conversations that use the short form: "PHY Interface for the PCI Express*, SATA, USB 3.2, DisplayPort* and USB4* Architectures Specification", Revision 7.1, dated September 2025, Intel reference number 643108. The desk downloaded and read that document on September 6, 2026, and every figure on this page comes from it. The usual way to say what the interface is for is that it sits between a controller, the MAC, and the analog PHY that drives the wires, written down so a PHY can be designed once and reused across several serial protocols. That framing is common industry usage rather than a sentence the desk could trace to a page of the document it read. What the document itself settles is narrower, and it is below.
What does revision 7.1 say it covers?
The scope statement answers that in one sentence, and settles a second question at the same time: which revision of each protocol the interface is measured against. Five architectures, five reference documents, named in a row. For a reader holding a datasheet, that sentence is also the fastest check that the PIPE revision in hand matches the silicon generation on the other side of the table.
"This revision includes support for PCIe implementations conforming to the PCIe Base Specification, Revision 7.0, SATA implementations conforming to the SATA Specification, Revision 3.0, USB implementations conforming to the USB Specification, Revision 3.2, DisplayPort implementations conforming to the DisplayPort 2.0 Specification, and USB4* implementations conforming to the USB4* Specification v2.0."
Seven signalling rates, four encodings
The rate tables name seven PCI Express signalling rates, 2.5, 5.0, 8, 16, 32, 64 and 128 GT/s, with 2.5 the lowest named and 128 the highest. Each row comes with the PCLK frequencies and the interface widths a PHY may present for it. The encoding table is shorter: it names 8b/10b, 128b/130b and 1b/1b for the SerDes variant of PIPE, and 128b/132b for USB at 10 GT/s, and the table of contents ties 128b/130b to PCIe 8, 16 and 32 GT/s. What the 64 and 128 GT/s rows carry as a line code is not settled by the extract read for this page, and the desk leaves it there rather than filling the gap. The same rates, read from the same revision, are set out in the link speed table on this desk.
| Encoding named | Where the document places it |
|---|---|
| 8b/10b | Listed for the SerDes variant of PIPE |
| 128b/130b | Tied to PCIe 8, 16 and 32 GT/s in the table of contents |
| 1b/1b | Listed for the SerDes variant of PIPE |
| 128b/132b | Tied to USB at 10 GT/s |
Why does a PHY document name the LTSSM?
Because the state machine that brings a link up works across that same boundary. The layer table names it in full, "Link Training and Status State Machine (LTSSM)", and the normative text names the states: Detect.Quiet, Polling, Configuration, Recovery, L0, L0s, L1, L2, Loopback and Disabled. One passage shows two of them in motion: "the receiver detection operation in the PCIe LTSSM state Detect.Quiet should be bypassed and the LTSSM should automatically proceed to Polling." The same passage recommends that a transition back to Detect from Polling on a timeout be followed by a subsequent transition to Polling, either on electrical idle exit detection or after a 30 to 100 ms timeout.
That is where this reading stops. The roles usually given to these states, Detect waiting for the electrical presence of a device at the far end of the link, Recovery letting a link retrain without a full re-enumeration, are common industry usage rather than something the desk could trace to a document it read. The states exist and are named in the PIPE specification; what each one does in detail belongs to how a link trains, and to the base specification behind it.
What the interface is not
It is not the PCI Express base specification. The scope statement keeps the two apart: this revision supports implementations conforming to the base specification, revision 7.0, which makes the base specification the rulebook and PIPE the boundary between two blocks of a design that both have to follow it.
It is not a compliance program, and nothing in the document read for this page was read as one. The desk keeps a separate note on how a compliance program works, and the description of workshops and published lists behind that note could not be verified against pcisig.com, a site this environment would not fetch.
And it is not a subject with a wide secondary literature. The desk searched the PCI Express article for the strings "LTSSM" and "Link Training and Status State Machine", and neither appears in it. No dedicated article exists for PIPE. A reader who stops at the general reference finishes it without the name of the state machine that brings the link up.
Reading a copy in hand
Three marks are worth checking before a figure is quoted from any copy: the revision, 7.1; the date, September 2025; the reference number, 643108. The document is published by Intel Corporation and gives an address inside itself for feedback, [email protected]. That last detail is a more useful test of a copy than it looks: a copy that cannot say where its corrections go is not the document the desk read.
If the point is to check a PHY claim, the order that pays is the scope statement, then the rate row for the speed printed on the datasheet in front of you, then the layer table for the encoding named there. Past those three places, quote the PCIe base specification instead. It is a different document, and the scope statement is the one that defers to it.
An address this domain used to serve
Before it was a reading desk, this domain's addresses appear in the Intel E7525 Memory Controller Hub datasheet of June 2004, which sent readers to document 300312-001 at a workgroup address on this host, in the passage about the receiver compliance eye diagram. That document could not be retrieved in 2026 from Intel, from PCI-SIG or from the Internet Archive, and the desk says so instead of describing it. The address is kept as a reading page, not as a restoration of whatever ran here before.
Checks to run on a copy of the document
- Confirm the copy reads Revision 7.1, September 2025, Intel reference number 643108 before quoting any figure from it.
- Read the scope statement and note which revision of the PCIe Base Specification it names for PCI Express.
- Find the rate row for the speed on your own datasheet and record the PCLK frequencies and interface widths listed with it.
- Search the layer table for the encoding your generation uses and check whether it is one of the four named there.
- Run a string search for LTSSM in any general reference you were about to cite, and note whether the name appears at all.
Common mistakes
- Quoting a state's behaviour from the PIPE document when the reading behind this page establishes only that the state is named there.
- Calling PIPE the PCI Express specification. It tracks the base specification named in its own scope statement, and it is not that document.
- Attributing the MAC-and-PHY framing to the specification's own wording when it is common industry usage the desk could not trace to a page it read.
- Reading the 64 and 128 GT/s rows as 128b/130b rows. The tie in the table of contents covers 8, 16 and 32 GT/s.