Why SPI Has No Universal Frame Format

Modules 1 through 3 built a complete account of how a bit gets from one chip to another: a shift-register ring clocked by a master, framed by chip select, with launch and sample edges fixed by two configuration bits.

Everything in those three modules was about signalling. This module is about meaning, and it has to open by establishing something uncomfortable.

If SPI standardizes the wires and the edges, why can't you write one decoder that understands any SPI device?

The answer is that SPI does not define a frame. Not a short frame, not a flexible frame — none. Where I²C specifies an address byte, a direction bit and an acknowledge, and where UART specifies a start bit, a character and a stop bit, SPI specifies nothing above the bit stream. That absence is the subject of this chapter, and it is the premise every remaining chapter in this module depends on.

1. What SPI Actually Standardizes

The complete list is short enough to write out. SPI defines:

• Four wires with fixed roles — a clock, two unidirectional data lines, and a select (Chapter 1.2).
• One clock source. The master drives SCLK; nothing else may (Chapter 2.1).
• A framing signal. CS delimits a transfer: assertion opens it, deassertion closes it (Chapter 1.5).
• Two configuration bits. CPOL and CPHA fix the idle level and which edge launches versus samples (Chapter 3.3).
• Simultaneous exchange. Every clock edge that moves a bit out also moves a bit in (Chapter 1.4).

That is the entire specification. Note what kind of statements these are: they are all about when a bit is valid and who drives it. None of them says anything about what any bit is.

2. What It Leaves Undefined

Everything else. Concretely, SPI does not define:

The last two are worth pausing on. SPI has no mechanism by which a device can say no. There is no acknowledge bit to withhold, no error code the bus understands, and no way to slow the master down. If a device cannot keep up or does not recognise a command, the bus carries on regardless and the master learns nothing.

3. The Same Bytes, Two Meanings

This is the chapter's claim made concrete. Below is one CS frame carrying four bytes — 0x02 0x00 0x10 0xA5 — on MOSI. The two lower lanes show how two entirely ordinary devices would each interpret exactly those bits.

Each cell is one byte time, not one clock cycle — at eight bits per byte this frame is 32 SCLK edges' worth of activity compressed into four slots.

The important thing about the figure is that the top two rows are the only rows that exist on the wire. The bottom two are interpretations, and the wire carries no information that would let you choose between them. A logic analyzer clipped to this bus can recover 0x02 0x00 0x10 0xA5 and the frame boundaries, and that is the limit of what any observer can know without the datasheet.

4. Why This Is a Design Choice, Not an Oversight

It is tempting to read the previous section as a list of things SPI forgot. It is more useful to read it as the bill for what SPI bought.

Every undefined field is silicon nobody has to implement. An I²C slave must decode an address, compare it against its own, drive an acknowledge within a fixed time, and handle clock stretching — a state machine of real size, in every device on the bus. An SPI slave must shift a register when clocked and stop when CS deasserts. On the smallest devices — a temperature sensor, a digital potentiometer, a shift-register expander — that difference is most of the digital logic.

Every undefined field is also a cycle nobody has to spend. I²C spends nine bit times on an address phase before any payload. SPI spends zero: CS is the address, asserted in parallel, costing no bus time at all. That is a large part of why SPI runs at tens of megahertz while standard-mode I²C runs at 100 kHz.

And the flexibility is load-bearing. Because SPI imposes no frame, a device is free to define whatever transaction shape fits it — a 12-bit ADC sample with no command at all, a flash command with a 24-bit address and a variable-length data burst, a 16-bit codec register write. Had SPI standardized an 8-bit-command-plus-address frame in 1980, every one of those devices would be paying for a structure that does not fit it.

The cost is paid exactly once, by you, at integration time: there is no such thing as a generic SPI device, so there is no such thing as a generic SPI driver.

5. What This Means for Software and Firmware

The layering that follows is the reason SPI driver stacks are shaped the way they are.

An operating system ships an SPI controller driver — it knows how to configure a mode, set a clock rate, assert a chip select and move a buffer of bytes. It knows nothing about meaning, because there is nothing about meaning to know.

Every device then needs its own driver on top, which knows that 0x03 is a read, that the address is three bytes big-endian, and that eight dummy cycles follow. That device driver cannot be derived from the bus specification, because the bus specification does not contain it.

Engineers who come to SPI from a networking or USB background often expect enumeration — a way to ask a device what it is. There is none. A master cannot discover anything about a slave. It cannot detect that a device is present, that CS is wired to the right pin, or that the device is the part number the schematic claims. Many devices offer a read-ID command as a convention precisely because the bus offers nothing, but you have to know the device to know which command that is — which is circular, and is exactly the point.

6. What a Logic Analyzer Can and Cannot Tell You

This is where the abstraction becomes a daily working reality.

A protocol analyzer's SPI decoder asks you, before it will decode anything, for the mode, the bit order and the word width. It asks because it cannot determine them. Those three parameters are not observable in the bit stream; they are agreements held at the two endpoints.

Given them, the decoder will produce bytes and frame boundaries — and stop. It will not tell you that byte one was a command, that bytes two through four were an address, or that the device was in a state where that command is illegal. Every commercial decoder that appears to do so is running a device-specific plug-in that someone wrote from a datasheet.

So the honest statement of an analyzer's power on an SPI bus is:

• It can tell you what bits crossed, when, in which frame, and on which line.
• It cannot tell you what any of it meant, or whether it was correct.

That boundary is the reason the debugging sections throughout this module keep returning to the same discipline: on SPI, "I can see the right bytes on the analyzer" is a much weaker statement than it feels like, and §9 is what happens when it is trusted too far.

7. What Verification Inherits

Chapter 3.8 §6 established that an SPI monitor must sample according to a configuration object rather than adapting to the DUT. This chapter explains why that is not a stylistic preference but a structural necessity, and extends it.

There is no protocol-level notion of a legal SPI transaction. A monitor can check that CS framed the transfer, that SCLK was parked correctly, that the right number of edges occurred, and that nothing drove MISO while deselected. It cannot check that a transaction was valid, because validity is a device property and the bus has no opinion.

The practical consequence is a split every SPI environment ends up making, whether or not it is made deliberately:

   // Everything here is an AGREEMENT between endpoints, not an observable.
   // A monitor that tried to infer any of it would be guessing; a monitor
   // that adapts to the DUT (Chapter 3.8 §6) would hide exactly the bugs
   // it exists to find.
   class spi_cfg extends uvm_object;
       // --- bus-level: the MOST a protocol checker can legitimately use ---
       rand bit [1:0] mode;        // CPOL, CPHA        (Chapter 3.3)
       rand int       width;       // bits per transfer (Chapter 4.2)
       rand bit       msb_first;   // bit order         (Chapter 4.3)

       // --- device-level: NOT SPI. Belongs to a device-specific layer. ---
       int  cmd_bytes;             // Chapter 4.4
       int  addr_bytes;
       int  dummy_cycles;          // Chapter 4.5
   endclass

The line between those two groups is the line this chapter is drawing. A protocol checker built on the first group is reusable across every SPI device you will ever verify. A checker that reaches into the second group is a device model, and calling it an SPI checker will eventually mislead someone into reusing it where it does not apply.

8. Why This Chapter Has No RTL

Deliberate, and for once the justification is the chapter's entire thesis.

This chapter's content is an absence. Its claim is that SPI specifies no frame, and there is no way to implement an absence in hardware. A module purporting to demonstrate "no universal frame" would either re-implement Chapter 1.3's shift core — which already exists, already shifts bits with no notion of meaning, and would teach nothing new — or invent a frame, which would contradict the chapter.

The honest artifact for a chapter about a boundary is a description of the boundary, and §7's configuration split is it. Chapters 4.2 through 4.5 each take one item from §2's table of undefined things and build the hardware that a device's choice about it requires — which is the correct place for that RTL, because it is the level at which the decision actually exists.

9. Failure Signature — The Bytes Are Right and the Device Does Nothing

Symptom. A new SPI device is integrated. A logic analyzer on the bus shows exactly the bytes the datasheet's example transaction lists, in the right order, with CS framing them correctly and SCLK at a sane frequency. The device ignores them completely — no response on MISO, no observable state change.

Why this is confusing. Every observable the team has says the transaction is correct. On a bus with an acknowledge, this situation cannot persist silently: the device would NAK and the master would know. SPI supplies no such signal, so a completely-ignored transaction and a completely-successful one look identical from the master's side.

Plausible mechanisms, all consistent with the evidence.

• The word width is wrong — the master is sending four 8-bit transfers where the device expects two 16-bit ones, and although the bits are identical the device's internal framing lands differently (Chapter 4.2).
• The bit order is wrong, and the analyzer is configured with the same wrong assumption, so it displays what the master intended rather than what the device received (Chapter 4.3).
• CS is toggling between bytes when the device requires one continuous frame — so the device sees four unrelated one-byte transactions and discards each as an incomplete command.
• The device requires a preceding enable or unlock command that the datasheet documents elsewhere.
• CS is wired to the wrong device, or not wired at all, and the device never saw anything.

The discriminating observations. The decisive one is cheap and almost always skipped: check the analyzer's own configuration before believing its output. If it is set to MSB-first 8-bit and the device is LSB-first, the analyzer and the master share a misunderstanding and agree with each other about the wrong answer. Configure the decoder to raw bits, not bytes, and read the actual line.

Then check CS behaviour across the whole transaction, not just its presence — specifically whether it stays asserted across all four bytes. This distinguishes a framing error from a content error, and it is invisible if you are reading a byte list instead of a timing view.

Why the investigation goes wrong. Because "the analyzer shows the right bytes" is treated as ground truth, when in fact the analyzer is displaying an interpretation built on three parameters a human typed in. On a bus that defines no frame, the tool cannot validate the assumption it was given — which is §6's boundary, arriving as a wasted afternoon.

10. Common Misconceptions

11. Reason It Through

Work this before reading the answer.

You are handed an SPI bus capture with no documentation: SCLK, MOSI, MISO and one CS line, sampled cleanly at high rate. You are asked to determine what the transaction does.

What can you establish from the capture alone, what is unknowable, and what is the most you could infer with effort?

What you can establish with certainty. The physical facts. SCLK's idle level gives you CPOL directly (Chapter 3.1 §1) — read it while CS is deasserted. The clock frequency and the edge count per CS frame are countable. The frame boundaries are explicit. Whether MISO was driven or tri-stated outside the frame is visible (Chapter 1.2). And because MOSI transitions cluster around one edge direction, you can usually determine the launch edge and therefore infer CPHA — giving you the mode without being told.

What is unknowable in principle. Everything semantic. Whether the first byte is a command, an address or data. Which device this is. Whether the transaction succeeded — there is no acknowledge, so a perfect transfer into a device that ignored it looks exactly like a perfect transfer into one that acted on it. Whether any value is a register number, a sample or a checksum.

What is unknowable but guessable. Bit order and word width sit in between, and this is the interesting part of the question. Neither is observable, but both are constrained by evidence. If the edge count per frame is 32, the width is plausibly 8 with four transfers, or 16 with two, or 32 with one — CS tells you the frame, not the word. If MISO is all ones for the first eight bit times of every frame and meaningful afterwards, you are probably looking at a command phase followed by a response, which hints at structure (Chapter 4.4). And if one byte's plausible-looking value becomes more plausible when bit-reversed — an ASCII character, a small integer, a recognisable opcode — that is evidence about bit order (Chapter 4.3).

The honest summary. You can fully recover the signalling and nothing of the meaning. Every semantic conclusion is a hypothesis supported by pattern-matching against devices you have seen before — which is a real and useful skill, and is emphatically not the same as reading a protocol.

Why this exercise matters. It is the precise boundary of what bus-level verification can check, arrived at from the observer's side rather than the specification's. Every checker in this track lives inside the first list.

12. Understanding Check

13. Summary

SPI standardizes signalling and framing, and nothing above it: four wires, one master-driven clock, CS as the transfer delimiter, two bits fixing the edge behaviour, and simultaneous exchange. Every one of those defines when a bit is valid; none defines what a bit means.

Left undefined are transfer width, bit order, command encoding, addressing, transaction structure, read latency, error reporting and flow control. In particular there is no acknowledge and no flow control, so a device cannot refuse a transaction or slow one down — and an ignored transfer is indistinguishable from a successful one at the master.

That absence is a deliberate trade. It removes silicon from every slave, removes an address phase from every transaction, and lets each device define a transaction shape that fits it. The price is that there is no generic SPI device and therefore no generic SPI driver: meaning lives in a datasheet, and integration pays for it once, per device.

The same absence bounds every tool. A logic analyzer needs mode, width and bit order supplied before it can decode, cannot validate what it was given, and can never report meaning. A verification environment must split bus-level configuration, which supports reusable protocol checks, from device-level configuration, which does not — and a checker that blurs the two is a device model wearing the wrong name.

Chapters 4.2 through 4.5 each take one undefined field, examine the engineering behind a device's choice about it, and build the hardware that choice requires.

14. What Comes Next

Chapter 4.2 — Transfer Width takes the first item from §2's table. It asks why eight bits became the default when the bus has no native word size, what a 12-bit ADC or a 16-bit codec actually requires of a master, and why the bit counter that terminates a transfer is the master's private bookkeeping rather than anything the device can see — with a width-parameterized transfer engine in all three HDLs, and the failure signature a width disagreement produces.