Why Chips on a Board Need a Bus

Before you meet a single I²C signal, condition or address, answer the question the whole bus exists to serve: why does a board full of chips need a shared communication path at all? A processor could, in principle, be wired directly to every device it must configure and read back. Real boards almost never do that. The reason is not that direct wiring fails to work — for one or two devices it works perfectly well — but that its cost grows in a way the rest of the design cannot absorb.

This chapter builds the cost model the rest of the curriculum stands on. Once you can say what a chip-to-chip connection actually costs and how that cost behaves as devices are added, a shared serial bus stops being a component you memorise facts about and becomes the predictable consequence of an engineering constraint — and every awkward thing I²C does later starts to look like a price someone chose to pay on purpose.

1. A Connection Is Not a Wire

The word "wire" is what makes this problem invisible. On a schematic a connection is a line, and lines are free. On a manufactured board a single signal between two chips is a small stack of separate commitments, each with its own budget:

• A pin on each package. The signal has to leave one die and enter another, and a package has a finite number of connections. Pins are not simply consumed; they are allocated, and the allocation is decided early and is expensive to revisit.
• An I/O cell behind each pin. A pad, a driver, protection structures and their share of the I/O power domain. This is silicon area on both dies, spent on getting off the chip rather than on doing anything.
• A routed trace on the board. Copper that has to physically travel from one package to the other, around everything already in the way.
• The board resources that trace consumes. Routing channels between other components, and — once the channels run out — an additional layer, which is a step change in board cost rather than an incremental one.

None of this is unique to peripherals. It is the price of any signal crossing between packages. What makes it a scaling problem is who pays it, and how many times.

2. The Cost Concentrates on One Package

A peripheral pays for its own interface once. The processor pays for every peripheral's interface.

That asymmetry is the whole problem. A temperature sensor needs the pins for its own connection and no more, and it will never know how many other devices exist. The processor — or the FPGA, or the SoC — is the single component that must reach all of them, so every device added lands another interface on the same package, competes for the same finite pin count, and occupies more of the routing region immediately around that one part.

The area next to a large package is also the most contested space on the board. Every signal entering or leaving must escape from beneath the package footprint before it can travel anywhere, and that escape region is shared by memory interfaces, clocks, power delivery and everything else the part is responsible for. Peripheral control traffic — which is not performance-critical and not what the chip was bought for — is competing there with traffic that is.

So the honest form of the question is not "how expensive is one connection?" It is: how does the processor's cost grow as the board grows?

3. What "Doesn't Scale" Actually Means

Make the growth explicit. Suppose a design has N peripherals to control, and give each one its own private interface of W signals. The processor then spends N × W pins, N × W I/O cells, and N × W routed traces that all converge on the same package.

The arithmetic is deliberately simple, and the assumption is stated rather than measured — but the shape is what matters. Adding a device does not add a fixed, absorbable amount. It adds a whole interface, at the one place on the board that can least afford it.

Two things about reading a figure like this one.

First, the signal counts are an assumption carried through arithmetic, not a measured property of real parts. Different devices need different interfaces; the point survives whatever number you substitute, because the cost is multiplied by N either way.

Second — and this is the part a schematic hides — the diagram's tidy fan is the least realistic thing about it. Those twelve traces do not travel as three neat bundles. They leave the processor from wherever their pins happen to be assigned, cross the same congested escape region, and then find their way to three parts in three different places. The routing cost is not proportional to the number of signals; it is worse than that, because congestion is what happens when many traces need the same space at once.

4. Where the Growth Actually Hurts

It is worth being precise about which budget fails first, because designers meet these failures in a characteristic order.

Pins run out visibly. A package has a published pin count. Allocating them is an explicit, countable decision, and running short produces an obvious conversation: move to a larger package, or give something up.

Routing runs out quietly. Nobody declares that the routing channels are exhausted. Instead a board that used to route in four layers now needs six, or a length-matched interface has to detour, or a part cannot be placed where thermal considerations wanted it because its traces would have nowhere to go. The cost is real and lands on manufacturing, but it arrives as a series of small concessions rather than a single decision.

I/O area and power are paid silently on the die. Every additional interface is pads, drivers and protection, plus its share of an I/O supply. That expenditure is invisible on the schematic and permanent in the silicon.

5. Two Ways to Spend Less

Only two levers act on N × W, and they are not equally powerful.

Reduce W — make each interface narrower. Fewer signals per device is a direct saving, and it has a natural floor: a connection cannot be narrower than the minimum needed to carry information reliably in the direction it must travel. Useful, and bounded.

Reduce the multiplication — let devices share the same wires. This is the structural lever. If one set of wires serves every device, the processor's interconnect cost stops tracking N at all. Adding a peripheral becomes an act of attaching it to something that already exists, rather than provisioning a new interface for it.

Compare the two figures on the one quantity that matters: what the processor spends. In Figure 1 that quantity is proportional to the number of devices. In Figure 2 it is a constant. Everything else in this curriculum is a consequence of choosing the second shape.

The word to be careful with is shared. In Figure 2 the wires are not duplicated per device and then bundled — they are the same conductors, physically continuous, touching every attached part at once. That single fact is what makes the saving real, and it is also what creates every problem the rest of the curriculum solves.

6. Why Sharing Is Affordable Here

A shared path has an obvious drawback: devices cannot all use it at the same time. If one device is using the wires, the others are waiting. Space has been traded for time.

For some traffic that trade is unacceptable. A processor's path to main memory carries the data computation is actually waiting on, and deliberately making it narrow and shared would make the machine slower at its job.

Peripheral control traffic is not that kind of traffic, and recognising the difference is the engineering judgement this chapter exists to teach. Consider what a board actually asks of the devices in Figure 1:

• Configure a regulator at start-up, then occasionally adjust or read it back.
• Read a temperature every so often — a small value, at a rate set by how fast temperature physically changes.
• Read an identifier or a calibration constant out of a memory once at boot.

Each of these moves a very small amount of information, and — this is the decisive property — none of them is urgent on the timescale at which the wires are busy. A transfer that occupies the shared path briefly and infrequently leaves it free almost all of the time. Sharing is affordable precisely because the demand is low, not because sharing is free.

This is also why the same board happily runs both shapes at once. The interfaces that carry the work stay wide, fast and often point-to-point; the interfaces that carry configuration and status get shared and narrow. That is not inconsistency. It is two traffic classes being priced correctly.

7. What Sharing Costs You

The saving is not free — it is relocated. The moment several devices sit on the same conductors, questions appear that dedicated wiring answered implicitly:

Who is being addressed? With a private link, the wire is the addressing: a signal on it can only concern the one device at the far end. On shared wires every device sees everything, so the identity of the intended recipient has to be carried in the information itself.

Who is allowed to drive, and when? Two devices imposing different levels on the same conductor at the same time is an electrical conflict, not merely a confused message. Something has to guarantee it cannot happen.

How does a device know a transfer has started, or finished? On a private link the framing can be implicit. On shared wires the boundaries of one device's turn must be unambiguous to every device watching.

What happens when a device is slow, absent or broken? A private link fails privately. A shared path can be held up — or held down — by any one participant, which turns one device's problem into everyone's problem.

Those four questions are not incidental complications. They are the specification. A protocol is what a shared set of wires needs in order to behave like a set of private ones, and each question above is answered by a specific mechanism that this curriculum builds up in order. The cost of the shared topology is that this discipline has to exist, be implemented in hardware at both ends, and be got right.

8. Why This Matters to a Semiconductor Engineer

This is not background reading. The cost model above is why several ordinary tasks look the way they do.

Pin budget is an architectural constraint, not an afterthought. On an FPGA or an SoC, deciding how peripherals are reached is decided alongside package selection, and it is one of the hardest decisions to revisit late. An interface that saves pins buys design freedom everywhere else.

"Just add another interface" is a board-level cost you will be asked to justify. The instinct to give a troublesome device its own dedicated connection is sometimes right — but it spends pins, I/O area and routing that something else has a claim on, and the argument has to be made in those terms rather than in terms of convenience.

Shared media are where the interesting bugs live. A private link either works or does not. A shared path introduces failure modes that belong to the combination of devices rather than to any one of them, and no single device's datasheet describes them. Much of the debugging skill this curriculum teaches later exists because of the topology chosen here.

Verification scope follows topology. Verifying a point-to-point interface means verifying two endpoints. Verifying a shared one means verifying the rules that keep several independent participants from interfering — which is a different and larger problem, and it is why a testbench for this class of bus has to model more than the device under test.

9. Common Misconceptions

10. Reason It Through

Apply the model to a question an engineer is genuinely asked. Work through it before reading the answer.

A board has a processor and four peripherals, each currently given its own dedicated interface. Marketing asks for three more peripherals of the same kind. A junior engineer proposes moving to a larger package with more pins.

What is the proposal actually buying? Pins, and only pins. It addresses the budget that fails most visibly while leaving the growth rate untouched — the new design still spends an interface per device, so the next three devices will pose the same question again.

Which costs does it leave unaddressed? The routing. Seven interfaces converging on one package is a congestion problem in the escape region, and a larger package with more pins can make that harder rather than easier by adding more signals that must all get out. It also leaves the per-interface I/O area and power on both dies untouched.

What does the shared alternative change? The processor's interconnect cost stops depending on the device count. Seven devices attach to what four were already using, and an eighth is a placement question rather than an architectural one.

What has to be true for that to be the right answer? That the traffic is small and not urgent — configuration, status, occasional readings. If one of those peripherals actually streams data the system is waiting on, it does not belong on the shared path, and the honest answer is a mixed design: a shared bus for the six that fit the profile, and a dedicated interface for the one that does not. Note the qualification, because it is where this reasoning is most often applied carelessly: the shared bus is the right default for this traffic class, not a universal answer.

11. Understanding Check

12. Summary

A connection between two chips is not a wire. It is a pin on each package, an I/O cell behind each pin, a routed trace, and the board routing channels and layers that trace consumes — drawn from budgets that are fixed early and expensive to revisit.

That cost concentrates on one package. A peripheral pays for its own interface once; the processor pays for every peripheral's. Giving each of N devices a private interface of W signals spends N × W pins, I/O cells and traces at the single point on the board least able to absorb them — and the routing cost is worse than proportional, because congestion is what happens when many traces need the same space at once.

Two levers act on that. Narrowing an interface reduces W and has a floor. Sharing one set of wires removes the multiplication, so the processor's interconnect cost stops tracking the device count. Sharing is affordable for peripheral control traffic specifically, because that traffic is small and not urgent — which is also why such a bus is correctly designed to be unhurried rather than fast.

The saving is relocated rather than eliminated. Shared conductors must answer, explicitly, who is addressed, who may drive and when, where a transfer begins and ends, and what happens when a participant misbehaves. A protocol is what a shared set of wires needs in order to behave like private ones — and that is the subject of everything that follows.

13. What Comes Next

You now have the constraint. Module 1 continues from it: the next chapter follows the reasoning from wide parallel interfaces down to the narrowest shared arrangement that still works, and the two after it place that bus in real hardware and weigh it honestly against the other board-level options. Those chapters are being written; browse the full path on the I²C tutorials index.

The same "the requirements conflicted, so the architecture changed shape" reasoning appears wherever an interconnect is designed rather than assumed. For the on-chip version of this argument — where the contested resource is die area and wiring between blocks rather than package pins — see Why AXI Exists and Why APB Exists, which reaches a conclusion strikingly close to this one for the same reason: a low-bandwidth control path should be cheap, not fast. For an integration convention that had to be shared across independent authors, see Why Wishbone Was Created. For the same cost reasoning applied to a link that carries the work rather than the configuration, see Evolution of System Interconnects and The Memory Hierarchy.