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. A Worked Board — Counting the Cost

Abstract growth arguments are easy to nod along with and hard to feel. Put numbers on one board.

Take a realistic supporting cast around a host — the five devices almost every board of this kind ends up carrying:

Now give each one a dedicated synchronous interface. Assume the minimum plausible bundle: a clock, a data line toward the device, a data line back, and a select — four signals. The assumption is stated rather than measured, and the conclusion survives whatever number you substitute.

Twenty signals is not a catastrophe on its own. The catastrophe is the last row. In the left column the sixth device is an architectural decision — find four more pins, route four more traces out of an already congested escape region, possibly move to a larger package. In the right column it is a placement question.

That is the difference between a cost that is large and a cost that grows. A large fixed cost can be budgeted once. A cost that grows with device count sets a ceiling on the design, and boards of this kind reliably acquire devices as they mature.

5. 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.

6. 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.

7. 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.

8. 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.

9. RTL Connection — Where This Cost Appears in Hardware

Everything above is a board-level argument, and it is worth being precise about where an RTL engineer actually meets it, because the answer is not in a behavioural description at all.

A peripheral's interface appears in hardware as a port bundle on a module boundary. Give five peripherals their own interfaces and the host's top level carries five such bundles — five groups of ports, each mapping to its own package pins, each needing its own I/O cells and its own escape path. Sketched as an interface, the contrast is stark:

   // Dedicated: the host's top level grows a bundle per device. Twenty signals,
   // twenty pins, five escape paths — and a sixth device edits this port list.
   module host_dedicated (
       input  logic clk,
       // --- PMIC ---------------------------------------------------------
       output logic pmic_sclk,  output logic pmic_mosi,
       input  logic pmic_miso,  output logic pmic_cs_n,
       // --- temperature sensor -------------------------------------------
       output logic temp_sclk,  output logic temp_mosi,
       input  logic temp_miso,  output logic temp_cs_n,
       // --- EEPROM, clock generator, board management ... four more each --
       output logic eeprom_sclk /* ... */
   );
   endmodule

   // Shared: one bundle, whatever the device count. A sixth device does not
   // appear here at all — it attaches to conductors that already exist.
   module host_shared (
       input  logic clk,
       inout  logic bus_data,   // one shared information conductor
       inout  logic bus_clk     // one shared timing conductor
   );
   endmodule

That fragment is an interface sketch, not an implementation — there is no body, and deliberately so. It is here because a port list is the most honest place to see N × W: the left module's boundary grows with the device count and the right module's does not.

Notice one detail that will matter for the whole rest of the curriculum: the shared version's ports are inout, not output. A dedicated interface has a direction per wire because exactly one device drives each. A shared conductor does not — which is a genuine hardware problem rather than a keyword choice, and it is the subject of Module 2.

No executable RTL or testbench appears in this chapter, and that is a deliberate judgement rather than an omission. This chapter's subject is a physical cost — pins, I/O cells, routed copper, board area. None of it is behaviour, so there is nothing a simulation could demonstrate and nothing a testbench could check. Writing a module here to satisfy a quota would teach syntax in place of the argument. Executable RTL arrives in Chapter 1.2, where serialisation gives us a real hardware abstraction with real cycle-by-cycle behaviour worth simulating.

10. 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.

11. Debugging Mentality — Interconnect Architecture Is Not a Protocol Bug

It seems early to talk about debugging, but this chapter establishes a triage habit that pays back for the whole curriculum, and getting it backwards wastes days.

When a board-level link does not work, the failures fall into layers that look alike from a distance and have nothing to do with each other:

Architecture. The interconnect cannot do the job at all — too few pins were budgeted, a device ended up sharing a path with traffic it cannot wait behind, or the bus was routed somewhere that loads it beyond what the design allows. No amount of protocol correctness fixes this; the symptom is that the design works on a bench with two devices and degrades as the real board fills up.

Connectivity. The right architecture, wired wrong — a swapped pair, a missing ground reference between boards, a device whose supply is not up yet. These produce total, reproducible silence rather than intermittent corruption.

Protocol. The wires are right and the conversation on them is wrong. This is the layer most engineers reach for first, and it is the last one worth suspecting on a new board.

The productive habit is to ask, in order: is this design capable of working, is it connected, and only then is it talking correctly? The cost model in this chapter is what makes the first question answerable — a design whose interconnect budget was never checked against its device count has an architectural problem wearing a protocol problem's clothes.

Chapter 1.3 makes the first question concrete by showing where in a real system the bus sits, and Module 2 supplies the electrical evidence that separates the second layer from the third.

12. Common Misconceptions

13. 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.

14. Understanding Check

15. 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.

16. What Comes Next

You now have the constraint. Module 1 continues from it: Chapter 1.2 follows the reasoning from wide parallel interfaces down to the narrowest shared arrangement that still works, Chapter 1.3 places that bus in real hardware, and Chapter 1.4 weighs it honestly against the other board-level options. 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.