4 ms·

One question I always have about new PCIe standards is how much cruft is caused by the insistence on backwards compatibility with previous PCIe versions? If you

One question I always have about new PCIe standards is how much cruft is caused by the insistence on backwards compatibility with previous PCIe versions? If you were designing a brand-new protocol to do the same things that PCIe does without having to maintain backwards compatibility, what would that new, optimized protocol look like? How much more performant could it be relative to PCIe? EDIT: Changed PCI to PCIe.

vel0city 5y ago
FWIW, PCI-e has never had backwards compatibility with PCI. They're two vastly different protocols that were somewhat standardized by the same standards body. So, PCI-e has always been vastly more performant than PCI since 2004.
- mikepurvis 5y ago
  They're not very relevant nowadays, but PLX and others make bidirectional PCI-PCIe bridges that I think were mostly used so that companies could ship transitional products— eg, do a new board layout that accommodates the PCIe slot/power/whatever, but add the bridge IC to it so that you don't have respin your super fancy custom ASIC.
simcop2387 5y ago
Check out CXL, it uses the same electrical standards but new protocols on top. There's a good servethehome video on it too. The end goal is to enable non-local memory pooling and other flexibilites to devices. It's a bit of the next evolution of things like DPUs and other datacenter mish-mashing of hardware. https://youtu.be/Mp9L7OClb2U https://youtu.be/Mp9L7OClb2U
Tuna-Fish 5y ago
> what would that new, optimized protocol look like? Exactly like PCIe 6.0, but with a slightly simpler negotiation process and none of the fallback modes. > How much more performant could it be relative to PCIe? It would have the same performance, but be slightly cheaper to implement. When two PCIe devices are connected to each other, they don't start in any data transfer mode, they start in a complex autonegotiation mode [0], where they find out the width of the link, the maximum protocol version that each side support, and the maximum speed that the connection between them can support. They were forward-thinking enought to make sure that this process can support pretty much any kind of protocol that does packet switching over LVDS signaling. Since packet switching over LVDS is still the best game in town, they are not overly burdened by backwards compatibility, other than having to also carry all the previous versions with them in the interface controllers. 6.0 changed to a completely different kind of packet system to support FEC, and no-one other than the implementors of the interface controllers have to care. Because PCIe is so flexible, it won't be unseated until there is some radically new kind of signaling that is better than LVDS on copper, say some kind of optical link. And even then, the successor is almost certain to be a variant of PCIe, just with a new physical layer. [0]: PCIe LTSSM. I sadly cannot link the spec here because it requires registration but have the diagram someone kindly ripped for SO: https://i.stack.imgur.com/QYyCM.png https://i.stack.imgur.com/QYyCM.png

vel0city 5y ago

FWIW, PCI-e has never had backwards compatibility with PCI. They're two vastly different protocols that were somewhat standardized by the same standards body. So, PCI-e has always been vastly more performant than PCI since 2004.

mikepurvis 5y ago
They're not very relevant nowadays, but PLX and others make bidirectional PCI-PCIe bridges that I think were mostly used so that companies could ship transitional products— eg, do a new board layout that accommodates the PCIe slot/power/whatever, but add the bridge IC to it so that you don't have respin your super fancy custom ASIC.

simcop2387 5y ago

Check out CXL, it uses the same electrical standards but new protocols on top. There's a good servethehome video on it too. The end goal is to enable non-local memory pooling and other flexibilites to devices. It's a bit of the next evolution of things like DPUs and other datacenter mish-mashing of hardware. https://youtu.be/Mp9L7OClb2U https://youtu.be/Mp9L7OClb2U

Tuna-Fish 5y ago

> what would that new, optimized protocol look like? Exactly like PCIe 6.0, but with a slightly simpler negotiation process and none of the fallback modes. > How much more performant could it be relative to PCIe? It would have the same performance, but be slightly cheaper to implement. When two PCIe devices are connected to each other, they don't start in any data transfer mode, they start in a complex autonegotiation mode [0], where they find out the width of the link, the maximum protocol version that each side support, and the maximum speed that the connection between them can support. They were forward-thinking enought to make sure that this process can support pretty much any kind of protocol that does packet switching over LVDS signaling. Since packet switching over LVDS is still the best game in town, they are not overly burdened by backwards compatibility, other than having to also carry all the previous versions with them in the interface controllers. 6.0 changed to a completely different kind of packet system to support FEC, and no-one other than the implementors of the interface controllers have to care. Because PCIe is so flexible, it won't be unseated until there is some radically new kind of signaling that is better than LVDS on copper, say some kind of optical link. And even then, the successor is almost certain to be a variant of PCIe, just with a new physical layer. [0]: PCIe LTSSM. I sadly cannot link the spec here because it requires registration but have the diagram someone kindly ripped for SO: https://i.stack.imgur.com/QYyCM.png https://i.stack.imgur.com/QYyCM.png