Skip to content

PCIe · Module 1

PCI Limitations — The Ceilings That Remained

What stayed hard about PCI after everything it improved over ISA: one finite shared bandwidth resource, ownership that must be arbitrated, and frequency, width, and device count that each stop scaling cleanly.

Chapter 1.3 made the case that PCI was a genuine success — processor-independent, self-describing, capable of bus mastering and efficient bursts. Nothing in this chapter retracts that. PCI did not fail; it was overtaken. Its limitations surfaced because what systems asked of an interconnect kept growing, and a design that answers the question of 1992 extremely well is still answering the question of 1992.

So the question here is narrow and concrete: what remained fundamentally difficult about PCI even after everything it improved?

1. What PCI Changed, and the One Thing It Did Not

PCI's improvements were real and they were about how devices use a bus: a defined protocol reached through a host bridge rather than a slot-level extension of the processor's signals, standardized configuration in place of jumpers, general bus mastering, and bursts that amortise setup cost across many data phases.

Read that list again and notice what every item has in common. Each one improves the efficiency, portability, or manageability of access to a shared medium. Not one of them changes the fact that the medium is shared.

That is the whole of this chapter. PCI made a shared bus about as good as a shared bus can reasonably be made — and then ran into the properties that belong to being a shared bus rather than to any decision PCI's designers got wrong.

2. Shared Bandwidth Is One Finite Resource

Start with the property that is easiest to state and easiest to misread.

A PCI bus has a finite aggregate transfer capacity. The devices attached to it do not each receive that capacity independently. They divide it. When one bus master is transferring, it is occupying bus time that no other master on that same bus can use for its own transfer at that moment.

This means device bandwidth on a shared bus is not a property of the device. It is a property of the device and everything else attached alongside it — including traffic that has nothing to do with it and may vary unpredictably. A device that performs acceptably in a lightly-populated system can perform quite differently in a busy one, without anything about the device having changed.

A shared PCI bus under growing demand: a host bridge connects to one shared PCI bus that four devices attach to. Devices A, B and C compete for bus time, and a later-added Device D draws from the same finite pool of capacity rather than adding any.Host bridgeCPU + memory sideShared PCI busone finite pool ofcapacityDevice Acompetes for bus timeDevice Bcompetes for bus timeDevice Ccompetes for bus timeDevice Dadded later — same poolbridges12
Figure 1 — one shared resource under growing demand. Every device attached to the PCI bus draws from the same finite pool of transfer capacity, and ownership of the bus must be arbitrated because only one master can be transferring at a time. Attaching Device D adds another source of demand on that pool; it does not add transport capacity for the devices already there to use.

3. Arbitration Allocates the Resource — It Does Not Create More

This distinction is worth being careful about, because it is where reasoning most often goes wrong.

Arbitration decides which requester owns the bus. It is a scheduling mechanism operating over a fixed resource. A better arbitration policy can change who waits and for how long — it can prioritise latency-sensitive traffic, prevent starvation, or distribute access more evenly. What it cannot do is increase the total amount of data the bus moves per unit time.

It also follows that arbitration is not the underlying problem. Arbitration exists because the medium is shared. Removing or improving it would not remove the sharing; it would only change how the sharing is managed. If you find yourself thinking "the fix is smarter arbitration," you have identified an optimisation, not a solution.

There is a genuine cost associated with ownership — changing which device drives the bus is not instantaneous, and time spent on that changeover is time not spent moving data. PCI reduces this cost in sensible ways, including by allowing arbitration for the next owner to proceed while a transfer is still running. But treat that overhead as a second-order effect. Even if the handover were free, the capacity would still be finite and still be divided.

4. Why Raising the Clock Stops Working

The obvious response to "not enough bandwidth" is a faster clock. On a shared parallel bus, that lever gets progressively harder to pull.

At the observable level: as the frequency rises on an interface where many devices attach to the same parallel wires, the timing margins available to every participant shrink and the electrical behaviour of the shared medium becomes harder to control. The bus does not stop working at some clean threshold — it becomes progressively more difficult to build, qualify, and populate, until the engineering cost of the next increment stops being worth paying.

A telling consequence, visible in the PCI family's own history, is that pushing the clock up tended to tighten the constraint on how many devices a bus segment could carry. Frequency and device count stopped being independent choices: higher speed came at the price of fewer attachments, which is a strange property for something whose purpose is to let you attach things.

That is the symptom, and it is what this chapter owns:

A shared parallel bus cannot be frequency-scaled indefinitely simply by choosing a faster clock.

Why frequency, device count, and physical topology interact so badly is a question about the electrical behaviour of a multi-drop medium, and it has its own chapter. Take the symptom now; Chapter 1.6 supplies the mechanism.

5. Why Widening the Bus Stops Working

The other obvious lever is width: move more bits per transfer. This also runs out, for reasons that are easier to see.

Width is expensive in a way that compounds across the whole system. A wider bus means more pins on every device that attaches to it, more traces routed across every board that carries it, larger connectors, and more signals that must all satisfy their timing requirements together rather than individually. The cost is paid by every participant, including devices that had no need for the extra width.

So widening is not a free dimension you can extend at will. It is a trade that raises the cost and difficulty of every attachment in exchange for more bits per transfer — and it does nothing about the fact that those transfers still contend for one shared medium. Here too, the deeper account of why keeping many parallel signals aligned becomes the binding constraint belongs to Chapter 1.6.

6. Why Attaching More Devices Is Not Free

Adding a device to a shared bus has three effects at once, and only the first is usually noticed:

  • Another source of demand now draws on the same finite pool of transfer capacity.
  • Another participant now contends for ownership, so the allocation problem grows.
  • Another electrical attachment now exists on the shared medium — and attachments are not free from the medium's point of view, which is what constrains how many can coexist at a given speed.

The first two are consequences of sharing capacity; the third is a consequence of sharing wires. Together they produce the property that makes a shared bus awkward as a foundation for expansion: the thing you attach devices to gets harder to operate as you attach devices to it. The mechanism behind that third point — why an attachment costs the medium anything — is again Chapter 1.6's subject, not this one's.

7. Faster Variants Extended PCI Without Changing Its Shape

The PCI family did not stand still. Higher clock rates, wider data paths, and successor variants such as PCI-X extended the useful life and performance of the architecture considerably, and they were competent engineering that kept the ecosystem viable for years.

They also make one point better than any argument could:

Increasing width and frequency raised the ceiling. It did not change what kind of ceiling it was.

Every one of those extensions produced a faster shared bus. The capacity was larger, and it was still one pool divided among the attached devices; ownership still had to be arbitrated; attachments still constrained achievable speed. Each increment also tended to be harder-won than the last. That pattern — real gains, rising difficulty, unchanged architecture — is the signature of a design being extended rather than replaced.

The exact frequencies and widths involved are not the lesson and are deliberately omitted. What matters is the shape of the curve, not the points on it.

8. What AGP Already Indicated

Chapter 1.4 supplies a piece of corroborating evidence worth one paragraph.

When graphics demand grew beyond what sharing the general bus could comfortably serve, the industry's answer was not to scale PCI to meet it. The answer was to take that traffic off the shared bus and give it a dedicated path. That is a revealing choice: faced with a device the shared model could not serve well, the practical response was to route around the shared model rather than extend it.

One exception for one device class does not establish a general conclusion, and the question of whether that kind of specialisation could work as a general strategy belongs to Chapter 1.7. Read AGP here simply as a data point consistent with everything else in this chapter.

9. These Are Symptoms — The Explanation Comes Next

It is worth being explicit about what has and has not been established, because the distinction is the spine of this module.

You now know what stopped scaling cleanly on PCI:

  • frequency — a faster clock gets progressively harder on a shared parallel medium
  • width — more bits cost pins, traces, and routing across every attachment
  • device count — each addition draws on the pool, contends for ownership, and loads the medium
  • aggregate bandwidth — one finite capacity, divided, no matter how well it is managed

What you do not yet have is the explanation. Nothing above says why a shared parallel bus makes frequency, device count, and physical topology interact so badly — why those dimensions cannot simply be traded against each other. That question is about the electrical behaviour of a multi-drop medium and the timing relationships between many parallel signals, and it is the entire subject of Chapter 1.6.

Two further pieces follow it. Chapter 1.7 takes the system-level view: what happens as device counts and unlike bandwidth demands grow together, and why specialisation of the AGP kind is not a general answer. Chapter 1.8 then asks the constructive question — given all of it, what properties must a replacement architecture have?

Resist the temptation to jump ahead. The reason this module spends four chapters on the problem before naming the solution is that PCIe's design only looks inevitable once you can state precisely what it had to fix.

10. Common Misconceptions

11. Real Engineering Relevance

The transferable idea here is one of the more useful distinctions in interconnect design:

Optimising access to a shared resource is a different activity from removing the shared-resource bottleneck.

PCI is a thorough demonstration of the first. Better protocol, better configuration, better efficiency per unit of bus time, better arbitration behaviour — all genuine, all valuable, none of them changing the aggregate capacity available to be shared.

You will make this distinction constantly. When an SoC interconnect saturates, when several masters contend for one memory port, when a shared channel becomes a bottleneck, the available responses fall into the same two categories: schedule the contention better, or stop sharing. The first is cheaper and often sufficient. The second is what you reach for when the demand has structurally outgrown the resource — and knowing which situation you are in is the judgement that matters.

The diagnostic question is simple: if the arbitration were perfect and the protocol overhead were zero, would the problem go away? If yes, you have an optimisation problem. If no, the resource itself is the constraint, and no amount of scheduling will fix it. For PCI in the early 2000s, the answer was no.

12. Understanding Check

13. Summary

PCI succeeded at what it set out to do, and its limitations are not a verdict on its design. They are the properties of a shared bus, which surfaced as system demands kept rising.

The bus carries one finite aggregate capacity that every attached device divides, so a device's usable bandwidth depends on its neighbours as much as on itself. Arbitration allocates that capacity and cannot increase it; it exists because the medium is shared, so it is a consequence of the constraint rather than its cause. Raising the clock becomes progressively harder on a medium with many parallel attachments, to the point where speed and device count trade against each other. Widening the bus costs pins, traces, connectors, and routing on every attachment, including those that gain nothing. Adding a device contributes demand, contention, and another attachment to the medium — never transport capacity. Later, faster variants raised the ceiling without changing what kind of ceiling it was.

Hold the model: PCI improved how devices use a shared bus, but it did not eliminate the fact that every attached device ultimately depends on the same shared electrical and bandwidth resource.

14. What Comes Next

This chapter named the ceilings. It deliberately did not explain them.

Chapter 1.6 — Shared Bus Problems supplies the mechanism: why a shared multi-drop electrical medium makes frequency, device count, and physical topology interact so badly, and why many parallel signals become progressively harder to keep usable as speed rises. Chapter 1.7 then scales the argument to the system level, and Chapter 1.8 turns the accumulated constraints into the properties a replacement architecture must have.

Revisit PCI for what the architecture achieved, AGP for the exception carved out of it, or Evolution of System Interconnects for the whole arc in one view. Browse the full path on the PCIe tutorials index.