How a Compliance Program Works

A compliance figure is a dated measurement

A compliance claim on a datasheet is a historical statement. It says that one product, on one day, met a defined set of tests drawn from one revision of the specification. Everything else the word seems to promise is supplied by the reader. The habit worth building is to treat the figure the way you would treat a scope capture: an instrument, a configuration and a date sit behind it. This page works through where the program came from, what a pass is measured against, and which of the documents underneath it you can still open today.

What does the testing actually consist of?

The commonly described shape of the program is a workshop, informally a plugfest, where companies bring hardware and test interoperability and signal integrity against each other, with products that pass recorded on a public Integrators List. The desk cannot put a document behind that description. The pages that describe it could not be reached during the research for this site, and the sources that were read do not describe the workshops or the list either. Treat it as common industry usage rather than something the desk could trace to a document it read. What can be said is that a compliance program exists to turn a specification into a measurable pass.

Where did the program come from?

The documented part of the story is older than the bus this desk follows. The consortium responsible for the PCI, PCI-X and PCI Express specifications is the PCI Special Interest Group, formed in 1992, and it formed as a compliance program: its initial purpose was to help computer manufacturers implement the original PCI specification. The checking side came first. Its specifications are distributed to members as free downloads, so the document and the apparatus for verifying a product against it have been separate artifacts from the start. A specification tells a part what to do. A compliance program is the attempt to find out whether a given part does it, and no amount of compliant wording on a box merges the two.

The eye, and the template drawn over it

Most of the signal-integrity side of a pass comes down to one picture. An eye diagram is built by sampling a digital signal repeatedly against the unit interval, the bit period, and overlaying the traces, which turns thousands of edges into a map of the signal's voltage probability density over time. On a PCIe lane it is the standard way to see the combined effect of channel noise, dispersion and intersymbol interference. An open eye means minimal distortion. A closed eye means interference and noise have degraded the signal far enough to risk bit errors at the receiver. The pass or fail line is usually an eye mask, a forbidden voltage and time template the measured eye has to clear. That term is common test-and-measurement practice rather than something the desk could trace to a document it read. The mechanics of the picture are taken further on the page about reading a receiver eye.

Which documents can you still open?

One of them this desk read end to end: the PHY Interface for the PCI Express, SATA, USB 3.2, DisplayPort and USB4 Architectures Specification, revision 7.1, September 2025, Intel reference number 643108. It names the signalling rates a PHY may present and the state machine that brings a link up, and it is the source behind the page on the PIPE interface.

The same research pass turned up a second address and a hole where its target should be. An Intel chipset datasheet of June 2004 tells the reader to refer to document 300312-001, at an address on this domain, for more information about the receiver compliance eye diagram. The document could not be retrieved in 2026 from Intel, from the consortium, or from the Internet Archive. The citation is real. The target could not be found, and this page does not reconstruct it.

What a pass does not cover

A pass on a given day says nothing about what a platform does when a link degrades afterwards, and the specification set documents that separately. The PCIe base specification, revision 7.0, defines Advanced Error Reporting in section 6.2 and Downstream Port Containment in section 6.2.11. Where the second is supported, a detected error disables the link to the entire sub-hierarchy below the faulting device, which leaves every device under it inaccessible until the link is reset and a subsequent slot-reset step completes. Where the first is supported, a faulting device may already be accessible at the first, Notification, step of a Linux kernel error-recovery sequence. That is behaviour under field conditions, a different question from the one a test day answers.

The concrete step is small. Take one compliance figure from a datasheet you are working with and trace it to a document: revision, date, section, and the name of the measurement. If the trail ends at a document you can open, the figure is usable. If it ends at the word compliant, that is a finding too, and the question to send back is which document the pass was run against.