Why SPI Exists

Before you meet CPOL, CPHA, the four modes or a single transaction diagram, answer the question the whole interface exists to serve: why does a board need something like SPI at all? A digital system is full of parts that must talk to each other — a processor and its boot flash, an FPGA and a converter, a controller and a sensor — and almost none of them are connected by a wide bus. They are connected by a handful of wires carrying one bit at a time, under a clock one side generates.

That is not a simplification anyone settled for. It is the shape a chip-to-chip link takes once you count what a connection actually costs. This chapter builds that argument, because every mechanical detail later in the curriculum — why there is a clock signal at all, why a select line frames a transfer, why the device rather than SPI decides what the bytes mean — is a consequence of the trade made here.

1. The Problem: Getting Data Between Two Chips

Start with the requirement, stated plainly. A device on a board needs to move control and data to another device on the same board. Not across a network, not across a backplane — a few centimetres, between two packages.

The cases look different but pose the same problem:

• A processor or FPGA must read its boot image out of a flash device before it can do anything else.
• An FPGA must pull conversion results out of an ADC, and push values into a DAC, at a rate the converter sets.
• An SoC must configure a sensor by writing its registers, then read measurements back.
• A controller must reach a peripheral that has its own register map and its own idea of what a valid access looks like.

Each is a request for the same primitive: let one device read and write another device's registers and data, reliably, without much hardware on either side. The question is not whether it can be built — it obviously can — but what a given way of building it costs when you build it on every peripheral on the board.

2. The Direct Answer, and What It Costs

The most direct connection is the one that mirrors how a chip already moves data internally: give the interface a wire per bit. Put eight data lines between the two devices, add whatever control lines the transfer needs, and a byte crosses in one clock.

This genuinely works, and it is what an on-chip bus does. Off-chip, the cost lands somewhere an on-chip bus never has to look: pins.

A signal that leaves a die does not just consume a wire. It consumes a pad and a package ball at each end, a PCB trace between them, routing area on every layer that trace crosses, and a share of the board's return-path and power-integrity budget. Package pins are one of the hardest limits in a real design — a pin count is chosen early, it is expensive to change, and everything competes for it: power and ground, the memory interface, high-speed links, clocks, debug, GPIO. Whatever is left is what the peripherals get to share.

Now scale it. A parallel port is not paid for once; it is paid for per device. Attach four peripherals with a byte-wide port each and the interface alone has consumed dozens of pins on the controller — before the memory interface has asked for anything. On an FPGA you can sometimes afford that. On a cost-sensitive SoC or a small microcontroller you cannot, and on the peripheral side it is worse: a small sensor in a tiny package may have only a handful of pins in total, so a byte-wide port is not a trade-off for it, it is impossible.

3. Trading Width for Time

If width is what costs, spend time instead. Send the bits one after another down a single wire and the receiving side reassembles them.

That is the trade, and it is a real trade in both directions. A serial link moves one bit per clock instead of eight, so for the same clock rate it carries an eighth of the data. What it buys is that the pin cost stops scaling with how many bits you want to move — and, crucially, the wires can be shared. Several peripherals can hang off the same data and clock lines, because only one of them is being addressed at a time, and the cost of adding one more device drops to roughly one extra select signal rather than a whole port.

Note what the trade is not. It is not "serial is better." It is that for a peripheral link — short distance, modest data volume, many devices, tight pin budget — the thing you are short of is pins, and the thing you have spare is time. A DRAM interface faces the opposite pressure and stays wide, which is why the memory hierarchy reaches a different answer from the same kind of reasoning. Choosing an interface means knowing which resource you are actually short of.

4. The Second Problem: Agreeing When a Bit Happens

Deciding to send bits one at a time creates a new problem immediately. The receiver sees a wire that changes level. It has to decide where one bit ends and the next begins — and a voltage on a wire does not say that by itself.

There are two ways to settle it.

Agree in advance. Both sides are configured with the same bit rate, the receiver watches for a transition that marks the start of a frame, and from then on it times each bit out internally — typically by running a much faster local clock and counting off intervals, so it samples near the middle of where it believes each bit is. This is the asynchronous approach, and it is what UART does. It costs no clock wire. It costs something else: both ends must be configured to the same rate beforehand, their independent clocks must stay close enough over a frame that the sampling point does not drift out of the bit, and the receiver needs recovery logic to find and hold that alignment.

Send the timing with the data. One side drives a clock line alongside the data, and that clock defines the transfer: a bit is presented, and an edge of that clock says when it is to be captured. This is the synchronous approach, and it is what SPI does.

Sending the clock changes what each side has to be able to do. There is no agreed rate to configure, because the rate is whatever the clock is doing right now — the receiving side does not need to know it in advance and does not need to recover it. There is no accumulating drift to tolerate, because the two sides are not running on independent timebases for the duration of a frame; they are using the same edges. The receiving logic reduces, in principle, to capturing a line on an edge someone else supplied.

5. What SPI Chose

Put the two decisions together and the interface almost writes itself.

One device is given control of the exchange. It generates the clock, it decides when a transfer starts and stops, and it decides which peripheral is being addressed. Everything else on the link responds. That device is conventionally called the master and the responding devices slaves — vendors increasingly write controller and peripheral for the same roles, and datasheets you meet will use either. This curriculum uses master and slave throughout, because that is what the majority of the parts you will read still say.

The link carries a small, fixed set of signals:

• SCLK — the clock the master generates. It is the timing reference for the whole exchange.
• MOSI — the data line driven by the master.
• MISO — the data line driven by the selected slave.
• CS — a select line, one per slave, that the master asserts to mark which device this transfer is for and to frame where the transfer begins and ends.

Two structural properties of that list matter now, and only in outline.

There are separate data lines in each direction. MOSI and MISO are distinct wires driven by different devices, so data can move both ways at the same time. Resist the temptation to read that as "MOSI is for writing and MISO is for reading" — it is not what the hardware does, and the mistake causes real bugs. Chapter 1.4 is where that gets built properly.

Selection is a wire, not an address. SPI has no in-band device addressing. The master does not transmit "device 3"; it asserts device 3's select line. That single decision is why SPI stays so simple, and it is also the origin of its most obvious scaling cost.

Read the pin arithmetic off the figure, because it is the whole argument of this chapter in one line. For N peripherals, a conventional SPI master spends three shared signals plus one select per device. The shared three do not grow. Compare that with a byte-wide port per peripheral and the reason this interface exists is no longer an opinion.

One qualification, so the figure is not over-read. Per-device select lines are the common arrangement, not the only one — some parts support a daisy-chained topology that trades the select-per-device cost for a different set of constraints, and wider variants of SPI add data lanes to buy back throughput. Chapter 1.5 covers topologies and Module 12 covers the wider variants. Neither changes the argument here.

6. What the Choice Costs

An interface that makes a strong trade has strong costs, and an engineer who cannot name them does not actually understand the interface. SPI's costs follow directly from the simplicity that makes it attractive.

No device addressing. Selection is physical, so every additional slave is another signal the master must generate, another pin, another trace, and another line whose timing is now part of your design. At two or three devices this is a non-issue. At twelve it is an architectural problem, and it is the pressure that makes designers reach for a bus that addresses in-band instead.

No universal higher-level format. SPI defines how bits are clocked across the wires. It does not define a command set, an address field, a length field, or a response format. Those exist, but each device defines its own — so "an SPI transaction" is only meaningful once you name the part. This surprises engineers coming from a bus with a specified transaction structure, and it is why reading a device datasheet is a core skill in this curriculum rather than an afterthought. Chapter 4.1 is devoted to it.

No protocol-level acknowledgement. There is no built-in mechanism by which a slave tells the master a transfer was received and accepted, the way some buses acknowledge each byte. Clock the transfer and the bits leave, whether or not anything was listening. Devices that need confirmation provide it in their own terms — a status register to poll, a data-ready line, a value you read back and compare — which is device behaviour, not protocol behaviour.

No arbitration. One device owning the clock and the select lines is the reason the hardware is small. It also means there is nothing in SPI that resolves two devices wanting the bus at once; the architecture simply assumes that does not happen.

Physics still applies. Nothing about SPI's simplicity suspends electrical reality. Every signal has a driver with finite strength, a trace with capacitance, and a receiver with a window in which it needs the data stable. Those bound how fast the link can actually run, and — as later chapters show — the binding constraint is often the round trip out to the slave and back rather than anything printed in the device's own timing table.

7. Reading the Trade-Off Honestly

It is common to see SPI summarised as "the fast one" against I²C's "the small one." Treat that as a slogan rather than a result.

What is structurally true is narrow and worth holding: SPI spends more wires than a two-wire addressed bus, and in exchange it gets a dedicated clock line, a dedicated data line in each direction, and no in-band addressing or acknowledgement to transmit. Those properties mean a straightforward SPI link has less protocol overhead per useful byte and simpler logic on both sides.

What is not safe is to convert that into a claim about any particular pair of devices. What a link actually delivers depends on the clock rate the slowest device on the bus will accept, on how much of each transaction is command and address rather than payload, on how long the master must wait before a device can answer, on how the board is loaded, on the round-trip delay at the frequency you chose, and on how the transfer is driven at the system level. Two boards using the same parts can differ substantially. The interface sets a ceiling and a cost structure; it does not set a throughput.

8. Why an RTL Designer Cares

Everything above is a specification in disguise. Read the trade-offs again as a list of blocks you will eventually write.

The master generates the clock, so there is a clock divider turning a system clock into SCLK at a rate the slowest device on the bus tolerates. Bits move one per edge, so there are shift registers on both the transmit and receive paths. Selection is a wire the master drives, so there is chip-select logic that asserts before the transfer and releases after it, cleanly. A transfer has a beginning, a body and an end, so there is a control FSM sequencing them and telling the rest of the system when it may hand over the next word. And because SPI fixes neither the transfer width nor which edge does what, a master worth reusing makes transfer width and mode configurable rather than hard-coding one device's habits.

That list is not a preview of some distant module. It is the direct image of this chapter's decisions in hardware, and it is why the RTL modules later in this curriculum spend as long on why the design is shaped that way as on the code. A designer who has only seen a finished SPI master can reproduce it; a designer who can derive it from the trade-offs can adapt it when the next device does something the last one did not.

9. Why a Verification Engineer Cares

The same decisions define what a testbench must observe and check — and, more usefully, what it can never assume.

Because there is no addressing, correctness includes who is selected: exactly one device, asserted before the clocking starts, released after it finishes. Because timing comes from a transmitted clock, correctness includes which edge did what, and whether the data was stable when it was captured. Because width is configurable, a checker cannot assume a byte — it has to be told, or infer it, and then verify that exactly that many edges occurred. Because there is no acknowledgement, nothing on the bus confirms success, so a scoreboard cannot wait for one: it has to reconstruct what was exchanged from the pins and compare it against what should have been.

And because SPI specifies no higher-level format, a checker that validates command and address structure is validating the device's contract, not SPI's. Keeping that boundary straight is what separates a reusable SPI agent from one that silently encodes one part's quirks.

Those are the outlines of a monitor, a reference model and a coverage model — built properly in Modules 16 and 17. Notice that they all follow from the same source: SPI verification is fundamentally about reconstructing a timed exchange and checking it, because the protocol itself confirms nothing.

10. Why an FPGA Engineer Cares

SPI reaches FPGA work from two directions, and they are not symmetric.

The FPGA as master is the common case and the comfortable one. It drives SCLK, so the transfer's timebase is derived from a clock the design already owns. Configuration flash, converters and sensors are all reached this way, and an FPGA is frequently the device that talks to the boot flash holding its own bitstream — so SPI is often running before the user design exists at all.

The FPGA as slave is the one that catches people out, and it is worth naming precisely now even though its treatment comes much later. A slave does not generate SCLK; it receives it. The signal that times the transfer arrives from outside the device, with no defined relationship to the system clock the rest of the design runs on, and it may start, stop and sit idle at arbitrary moments. That is not a coding inconvenience — it is a clock-domain question, and it is decided at the architecture stage, before any RTL is written. It also brings I/O timing with it: what the FPGA must guarantee about when it presents data, and what it requires about when data arrives, become constraints you write and close rather than properties you hope for.

This chapter deliberately stops at naming it. Module 15 is where the architectures, their trade-offs, the synchronisation strategies and the constraint work are built. What to carry forward is only this: who generates the clock is an architectural fact with consequences, and for a slave those consequences are the hardest part of the design.

11. Common Misconceptions

12. Reason It Through

Work this before reading the answer. It is the kind of question that opens a design review.

A small SoC must reach four peripherals: a boot flash, a high-rate ADC, and two configuration-only sensors that are written once at startup. The pin budget is tight. An engineer proposes giving the ADC its own byte-wide parallel port "because it is the fast one" and putting the rest on SPI.

What is the proposal actually buying? Per-transfer width for one device. The ADC would move eight bits per clock instead of one, so for a given clock rate its transfers finish in fewer cycles.

What does it cost? A whole port's worth of pins and traces, spent on one device — plus a second, different interface for the design to implement, constrain, verify and debug. The three SPI devices were nearly free to add once the shared signals existed; this one is not, because a parallel port cannot be shared with peripherals that do not speak it.

Is the premise even right? That is the part to challenge. "The fast one" is a claim about a device's required data rate, not about the interface. The question is whether the ADC's sustained sample rate, multiplied by its sample width and its per-transaction overhead, actually exceeds what the SPI link can deliver at a clock rate every device on that bus tolerates. Very often it does not, and the parallel port buys headroom nobody needed at a price that was already scarce. Sometimes it does — converters exist whose output rate genuinely outruns a single-bit serial link — and then the honest next question is whether a wider SPI variant closes the gap for a lane or two rather than a whole port.

What is the real risk hiding in the proposal? Not the ADC. The two configuration-only sensors are written once at startup and are latency-irrelevant, so they cost almost nothing on the shared bus — but each still costs a select line, and select lines are the part of SPI that scales with device count. If the pin budget is genuinely tight, that is where the scaling pressure lives, and it is a far more interesting conversation than the one about the ADC.

13. Understanding Check

14. Summary

SPI exists because of what an off-chip connection costs. A wire per bit is the direct way to move data between two chips, and it is what an on-chip bus does, but off-chip every signal consumes a pad, a ball, a trace and routing area at both ends — and that cost is paid per device. Under a real pin budget, a parallel port on every peripheral is not affordable, and on a small package it is not possible.

So a peripheral link trades width for time: send the bits one at a time, accept fewer bits per clock, and gain wires that can be shared across many devices. Sending bits serially then raises the question of where one bit ends and the next begins, and SPI answers it by transmitting a clock rather than by having both sides agree on a rate in advance — which removes rate configuration and drift, at the cost of one wire and of a new agreement about edges and stability windows.

What falls out is an interface in which one device owns the clock and the selection, data has a dedicated line in each direction, and a peripheral is chosen by asserting its select line rather than by transmitting an address. That buys simplicity on both sides and a marginal cost of about one signal per additional device. It gives up device addressing, any universal higher-level frame format, acknowledgement and arbitration — and every one of those omissions becomes something the engineer using SPI has to supply, verify or design around. That exchange, not the wire count, is what SPI is.

15. What Comes Next

You now have the argument. Module 1 turns it into a working model: master, slave and signal ownership establishes exactly who drives each line and when, the shift-register model makes the exchange concrete, and the full-duplex chapter settles what MOSI and MISO really do. Those chapters publish as the track rolls out; the index below tracks what is live. Module 2 then opens the timing contract this chapter deliberately deferred, and Module 3 derives the four modes from it rather than asking you to memorise them.

Browse the full path on the SPI curriculum index, or read the SPI protocol overview for a shorter orientation. For the asynchronous answer to the same bit-timing question, see What a UART Actually Is and Synchronous vs Asynchronous Serial Links; for how the choice is framed against other links, UART vs Other Interfaces. For the same "the requirements conflicted, so the interface changed shape" reasoning applied on-chip, see Why APB Exists and Why AXI Exists. For where the opposite pressure produces a wide interface instead, see The Memory Hierarchy and Flash.