Generations
What a revision keeps fixed
A specification revision is a calendar with fixed and movable feasts, and the reader who knows which is which reads it in minutes.
What survives a generation change
Every new PCI Express generation changes the per-lane rate and keeps the architecture: the lane, the link, the packetized transaction, the configuration space, the connector contract. Knowing which parts are fixed and which move is the whole skill of reading a new revision without starting over.
The fixed list is long and structural. A lane is still two differential pairs, full duplex, with the clock embedded in the stream. A link is still striped across its lanes by the same byte order. Configuration space still answers the same questions in the same places, which is why software written for the first generation still enumerates the newest. The card-edge connector contract, the slot sizes and the power budget structure, stays readable across the whole ladder. What moves is narrower and more specific: the rate per lane, the encoding that carries it, and the equalization machinery that keeps the channel open at the new speed.
The pattern of a calendar with fixed and moving parts is older than any bus. The guide that publishes a liturgical year guide organizes the whole year around the distinction: feasts fixed to a date, feasts moved by a rule, and a reader who knows which is which can navigate a calendar that changes shape every year. A specification revision is the same kind of calendar: the fixed feasts are the architecture, the movable ones are the rates.
Which parts actually moved?
Three, in every generation so far. The rate moves: each step of the rate ladder doubles or near-doubles the per-lane figure. The encoding moves less often but more consequentially: the early generations carried 8b/10b overhead, later ones moved to the much lighter 128b/130b scheme described on the encoding page, and the newest add forward error correction because the channel alone can no longer meet the error bound. The equalization moves with the rate: faster signals need more active compensation at the receiver, and each generation formalizes more of it.
What did not move is what makes the movement possible: the negotiation in the counted sequence lets a new card and an old slot settle at the fastest rate both support, which is the entire reason a generation can change without breaking the installed base.
| Element | Fixed or moving | Note |
|---|---|---|
| Lane structure | Fixed | Two pairs, full duplex, embedded clock |
| Configuration space | Fixed | Same questions in the same registers |
| Connector contract | Mostly fixed | Slot sizes and power structure persist |
| Per-lane rate | Moves every generation | The ladder's whole content |
| Encoding | Moves rarely | 8b/10b to 128b/130b, plus FEC at the top |
| Equalization | Moves with the rate | More of it is formalized at each step |
How do you read a new revision without relearning?
By asking which list a change belongs to. A new generation's announcement is a set of claims about the moving parts: the rate figure, the encoding consequences, the equalization requirements, the new compliance points those create. Everything else the document describes is the fixed architecture doing its ordinary work, and the reader who recognizes the fixed parts reads the announcement in minutes rather than weeks. The trick is conservative: when a feature is not explicitly on the moving list, assume it is fixed and go looking for the exception.
The bit-rate landscape this sits in is mapped in the list of interface bit rates, read on September 6, 2026, which places each generation's move against the rest of the industry's; and the encodings themselves are documented in the 8b/10b article and the 64b/66b-family article, read the same day.
Why does the fixed part matter more?
Because it is where the errors hide. A reader who assumes the architecture moved when it did not will misread a whole document; a reader who assumes a figure moved when it did not will quote a dead number. The revision reading is a two-list exercise: what the generation changed, and what it could not have changed without breaking the installed base it exists to serve.
Checks for reading a new generation
- Sort every claimed change into fixed or moving before trusting it.
- Check the negotiation rule first: the new rate still settles by the old machinery.
- Follow the encoding change to its overhead consequence before quoting a usable figure.
- Treat the connector contract as fixed until the document proves it moved.
Common mistakes
- Reading a new rate as a new architecture. The lanes, the striping and the software view did not move.
- Assuming backward compatibility is courtesy; it is the fixed part doing its job.
- Quoting a usable bandwidth before the encoding and FEC overhead is accounted.
- Relearning the document instead of reading its diff against the last revision.
A generation is a calendar, not a rewrite: the fixed feasts hold the year together, and the movable ones are where the work of reading actually is.
A revision does not rewrite the link: the encoded rates, the ordered set sequences, and the electrical limits that a given generation defines stay where the specification put them, and a later revision adds to that record rather than replacing it. What changes is the surrounding apparatus, the errata, the clarified tables, and the figures that move between documents. A reader who needs to know which number came from which revision, and which one still governs a design, can consult the dated notes collected at quoting a figure with its revision, where each entry names its source revision.
The page behind these facts
The fixed and moving division follows the PCI Express article and the bit-rate and encoding references linked inline, all read on September 6, 2026. The desk's own pages on the rate ladder and on encoding carry the figures generation by generation.