Bridge — Crossing Between Interconnect Architectures

Chapter 2.4 established how a hierarchy branches while every connection stays point-to-point. A Switch does that with PCIe on every one of its connections — it never leaves the architecture.

This chapter asks a different question:

What happens when a PCIe hierarchy must connect to an interconnect that follows different rules?

Not a faster or slower version of the same thing — a genuinely different architecture, with its own topology, its own way of expressing transactions, and its own conventions. That is not a forwarding problem. It is a boundary problem, and it needs a different kind of component.

1. Why a Boundary Component Is Needed

Module 1 tells you why this component had to exist.

Chapter 1.8 established that PCIe changed the transport architecture completely while deliberately preserving substantial software-visible continuity — architectural discontinuity underneath, compatibility continuity above. That choice protected the software ecosystem. It did nothing for hardware that already existed.

A large population of devices was built for the shared parallel bus of Chapter 1.3. Those devices expect a shared medium with the conventions that came with it. They cannot be attached to a PCIe Link, because a Link is a dedicated connection between two components speaking a different architecture entirely — the incompatibility is structural, not a matter of speed or connector shape.

So a transition needed something that could present each side with behaviour consistent with that side's architecture. On the PCIe side: a participant in the hierarchy, behaving as the architecture requires. On the other side: whatever that interconnect expects. In between: enough mediation that transactions can meaningfully cross.

That component is a bridge.

2. The Boundary Made Visible

The clearest way to see what a bridge does is to look at what sits on either side of it, because the two sides are not variations on a theme — they are the two architectures Module 1 spent its length distinguishing.

Read the figure as two halves. On the left, a dedicated connection joining exactly two components — no medium, no ownership to arbitrate. On the right, several devices attached to one set of wires, contending for it, with everything Chapter 1.5 and Chapter 1.6 described about how that behaves.

The bridge is the only place those two models touch.

3. What "Mediates" Means — and What It Does Not

It is tempting to imagine a bridge as a converter: each PCIe transaction becomes one legacy bus cycle, one-for-one, and everything else follows. That picture is too simple, and relying on it will produce wrong expectations.

The two architectures differ in more than encoding. They differ in topology — one point-to-point, one a shared medium. They differ in how a transaction is expressed and how a device is addressed. They differ in what happens when something is busy or unavailable. A component sitting between them is not performing a translation table lookup; it is participating properly in both architectures and reconciling their models well enough that communication crosses.

The accurate framing:

A bridge presents each side with behaviour consistent with that side's architecture, and mediates transactions and resources across the boundary.

That deliberately stops short of mechanism. The precise rules — how transactions are carried across, how resources on the far side are made reachable, what ordering guarantees hold across the boundary — depend on protocol details that later modules develop properly. Stating them now would require either hand-waving or inventing detail, and this chapter would rather defer than do either.

What is safe to carry forward is the consequence: because the two sides are genuinely different architectures, a bridge is a place where behaviour can differ. Devices on the far side are reachable, but they are not thereby PCIe devices, and the boundary is not transparent in every respect.

4. Bridge Is Not Switch

This distinction deserves its own treatment, because the components are adjacent in a diagram and entirely different in kind.

A Switch lives inside one architecture. Every connection faces PCIe. Its job is forwarding a transaction from the Link it arrived on to the Link it should leave by, and everything it touches follows the same rules. Nothing about the architecture changes as traffic passes through it.

A Bridge spans two architectures. At least one side is not PCIe. Its job is not forwarding within a uniform structure but reconciling two structures that do not share conventions. Something does change as traffic passes through it — that change is the entire reason it exists.

Notice the parallel with Chapter 2.2's distinction between a Root Complex and a Switch, which turned on the same question: which domains does this component touch? The Root Complex straddles PCIe and the processor and memory domain. A Bridge straddles PCIe and some other interconnect. A Switch straddles nothing — it sits wholly within PCIe.

That gives a clean three-way test for any multi-connection component:

5. What This Bought the Industry

The strategic point is worth one section, because it explains why the component matters historically rather than merely structurally.

A transition that required discarding every existing device would have been enormously expensive, and expense of that kind slows or prevents adoption regardless of technical merit. Bridging meant existing hardware could continue to be used while systems moved to the new architecture — the hardware counterpart to the software continuity Chapter 1.8 described.

Two qualifications keep this honest.

Not every PCIe system contains such a bridge. Bridging addresses a compatibility need. A system with no legacy devices to accommodate has no reason to include one, and many do not. Do not read Figure 1 as a required part of the architecture — it is a component used where the need exists.

Bridging is not a general answer to architectural change. It made a specific transition manageable by letting two models coexist at a defined boundary. It did not make the older architecture scale, and everything Module 1 established about why the shared bus ran out remains true of the devices on the far side.

6. Common Misconceptions

7. Real Engineering Relevance

For verification work, a bridge is best understood as a protocol boundary, and boundaries are where a disproportionate share of problems live.

Three habits follow from that framing.

Know which side owns a behaviour. A component on the PCIe side has obligations defined by PCIe. A device on the far side has obligations defined by its own architecture. When something misbehaves near a boundary, the first question is which side's rules were broken — because the two have different specifications and different correct answers.

Expect the models to differ, and find out where. The two architectures do not make identical guarantees, so assumptions valid on one side are not automatically valid on the other. Any property carried across a boundary is worth checking rather than assuming, and the differences that matter are exactly the ones a testbench should exercise deliberately.

Localise errors relative to the boundary. A failure originating on one side, a failure originating on the other, and a failure in how the boundary itself mediates are three different problems with three different investigations. A verification environment that cannot tell them apart will produce reports that point in the wrong direction.

The general lesson transfers past PCIe: wherever two architectures meet — protocol boundaries, clock-domain boundaries, power-domain boundaries — the boundary itself is a component with its own correctness obligations, not a transparent seam. Treating it as transparent is a reliable way to be surprised.

8. Understanding Check

9. Summary

A bridge connects two different interconnect domains and mediates enough of their transaction and resource models for communication to cross. It exists because PCIe's change of transport left a large population of hardware built for the shared parallel bus, and that hardware cannot attach to a Link — the incompatibility is structural.

The discriminator to keep: a Switch has PCIe on every connection and forwards within one architecture; a Bridge has a different interconnect on at least one side and crosses between architectures. That is the same test that separates a Root Complex from a Switch — which domains does this component touch?

Mediation is not one-for-one conversion. The two sides differ in topology, in how transactions are expressed, and in what happens when something is unavailable, so a bridge presents each side behaviour consistent with that side's architecture rather than translating mechanically. The consequence is that a boundary is where behaviour can differ: devices on the far side become reachable without becoming PCIe devices.

Two qualifications: not every PCIe system contains one, since bridging meets a compatibility need rather than an architectural requirement; and bridging did not make the old architecture scale — it let two models coexist at a defined boundary.

Hold the model: a bridge crosses between architectures; a switch forwards within one.

10. What Comes Next

The hierarchy can now branch through Switches and reach beyond itself through Bridges. That makes it considerably more complex than the simple tree of Chapter 2.1 — which raises a question this module has so far avoided.

Chapter 2.6 — Hierarchy Domains takes it up: once a structure can branch and deepen and cross boundaries, how is it organised so that software and hardware can identify where a given function actually sits? Structure without a way to refer to positions within it is not usable.

Chapters 2.7 through 2.9 then take the fabric view, the Link in depth, and the full switched-architecture comparison.

Revisit Switch for the component this chapter contrasts with, or PCI for the architecture on the far side of the boundary. Browse the full path on the PCIe tutorials index.