Document 300312-001, and Where That Reading Goes Now

A citation that no longer resolves

A chipset datasheet dated June 2004 sends its readers to a document number, and the address printed under that number now serves this desk. The citation still resolves to a page. The document it named does not come back from anywhere the desk could reach in 2026, and the distance between those two facts is the subject of this page.

The sentence that opens the story is short. The Intel E7525 Memory Controller Hub datasheet of June 2004 prints, in its passage about the receiver compliance eye diagram: "Refer to document 300312-001 at http://www.pciexpressdevnet.org/apps/org/workgroup/dgl/document.php?document_id=89 for more information." The path belongs to a developer network for PCI Express architecture, a document store addressed by number. The domain in that URL is the one you are reading now. What it serves today is an editorial desk that reads specifications, and it is neither that organization nor PCI-SIG.

The citation is verifiable. The document it named is not, and both statements belong in the same paragraph.

What did document 300312-001 contain?

This page cannot tell you, and that is the finding. The desk searched for document 300312-001 in 2026 and did not retrieve it from Intel, from PCI-SIG, or from the Internet Archive. No copy came back, so nothing here describes its contents; a page that described them would be writing fiction around a document number. What survives is the citation, which fixes two things: a number, and the subject of the passage that needed it, the receiver compliance eye diagram.

A reader arriving from the E7525 datasheet is not carrying a vague question about bus history. The reader is carrying a receiver-eye question, and a receiver-eye question still has a current answer. What the domain kept from its earlier life is a catalog sorted by product category, summarized on the archived roster page, a statement about a page rather than about anything still operating.

Where a receiver-eye question is answered now

An eye pattern is an oscilloscope-style display built by repetitively sampling a digital signal against the unit interval, the bit period, and overlaying the resulting traces. The overlay turns a probability density into a picture you can argue with. An open eye corresponds to minimal signal distortion. A closed eye means intersymbol interference and noise have degraded the signal far enough to risk bit errors at the receiver. It is the standard view of the combined effect of channel noise, dispersion and intersymbol interference on a link such as a PCIe lane, and it is what the 2004 passage pointed at.

The pass or fail form of that measurement, a forbidden voltage and time template the measured eye must clear, is common industry usage rather than a term the desk could trace to a document it read. For the subject a single eye sits inside, the PCI Express article is a fair second read. The page on reading a receiver eye takes the measurement apart in order.

The specification this desk read on September 6, 2026

For a PHY question, the document that comes back is titled "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. It is published by Intel Corporation and prints a feedback address, [email protected], inside itself. Its scope statement reads, verbatim: "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."

Read that scope statement before repeating anything about what a PHY supports. The rate tables name PCI Express signalling rates of 2.5, 5.0, 8, 16, 32, 64 and 128 GT/s, each with the PCLK frequencies and interface widths a PHY may present for it. The layer table names the encodings a PHY may implement: 8b/10b, 128b/130b and 1b/1b for the SerDes variant of the interface, and 128b/132b for USB at 10 GT/s. The table of contents ties 128b/130b to "PCIe 8, 16, and 32 GT/s", which matters whenever an overhead figure travels, because 20 percent belongs to 8b/10b and about 1.54 percent belongs to 128b/130b. Where that interface sits in a design is the subject of the page on what the PIPE interface is.

Which states does the same document name?

Link training turns a PHY question into a state machine question, and the PIPE layer table names that machine: the Link Training and Status State Machine, LTSSM. The normative text names the states Detect.Quiet, Polling, Configuration, Recovery, L0, L0s, L1, L2, Loopback and Disabled. One passage shows them moving: "the receiver detection operation in the PCIe LTSSM state Detect.Quiet should be bypassed and the LTSSM should automatically proceed to Polling. If the LTSSM transitions back to Detect from Polling due to timeout, it is recommended that a subsequent transition to Polling should occur either upon an electrical idle exit detection or after a 30 to 100 ms timeout."

The boundary of that reading belongs next to the quote. What this page can source is that these states exist and are named in a document with a revision number and a date. What it cannot source is the detailed behaviour of each state, or the ordering of every substate. The PCI-SIG compliance program is a separate item the desk has not verified from a document it read.

What a reader can hold instead

The 2004 citation belongs to the first generation of the technology, set down at 2.5 GT/s per lane over 8b/10b in 2003 and again in 2005, worth about 250 MB/s usable per lane, per direction. The raw rate has since moved to 128 GT/s, every generation on the way carries a release date precise to the day, and the usable byte figures sit on the rate ladder page.

Generation 3.0 is the row that teaches the encoding lesson: from 2.0 to 3.0 the raw rate rose by 1.6 times while the usable rate nearly doubled, because the encoding changed and the overhead fell. A cross-check from outside the specification family lands on the same revision: the Linux kernel's PCI error-recovery documentation independently cites PCIe r7.0, the revision the PIPE scope statement names, and the revision that defines Advanced Error Reporting in section 6.2 and Downstream Port Containment in section 6.2.11.

If you are the reader the 2004 datasheet was written for, the working sequence is narrower now. Note the number your datasheet cites and the date of the datasheet itself. Try the number at the publisher and at an archive. Then read the documents that do come back, scope statement first, and check each rate and state name against the tables before it reaches your own document.