Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • Reading Paths
  • Concept Map
  • How to Read the Diagrams
  • Part 0: What Is a Protocol?10
  • Part 1: Timing and Clocking11
  • Part 2: Encoding and Framing12
  • Part 3: Handshakes13
  • Part 4: Flow Control17
  • Part 5: Transactions19
  • Part 6: Concurrency and Performance17
  • Part 7: Ordering13
  • Part 8: Sharing and Arbitration12
  • Part 9: Deadlock and Liveness13
  • Part 10: Reliability and Recovery20
  • Part 11: Bring-Up and Link Management10
  • Part 12: Power8
  • Part 13: Shared State and Coherence9
  • Part 14: Security and Isolation7
  • Part 15: Specifying and Verifying11
  • Part 16: Protocols Dissected17
    • How to Dissect a Protocol
    • UART
    • SPI
    • I2C
    • APB
    • AHB
    • AXI4
    • AXI-Stream
    • PCI Express
    • DDR
    • CHI
    • Ethernet
    • USB
    • UCIe
    • CXL
    • Protocols Compared: Protocols Dissected
    • Drills: Protocols Dissected
  • Part 17: Capstones5
  • Part 18: Interview Preparation6
Loading lesson

‹Part 16: Protocols Dissected
  1. Topics
  2. First Principles of Hardware Protocols
  3. Part 16: Protocols Dissected
  4. SPI

Part 16 · Protocols Dissected · Foundation (F)

SPI

SPI dissected through the twenty questions: the master drives the clock and selects one slave, data shifts both ways at once, and nothing acknowledges anything. Why that makes it fast and simple, and what it leaves to each device's datasheet.

On this page

    Note

    Level: Foundation (F) · Answers: How do real protocols answer the fifteen questions?

    Before this: UART, Common-Clock Interfaces

    A microcontroller reads a flash memory chip at tens of megabits per second over four wires. It drives the clock itself, pulls the flash's chip-select low, shifts out a command and keeps clocking while the data shifts back. If the flash were absent, the microcontroller would read all ones and never know. SPI is fast because it checks nothing.

    How does SPI answer each question, and what does it gain by answering so few?

    Constraints first: what SPI had to work with

    Constraint

    SPI

    C1 Distance and medium

    Short: on one board

    C2 Bandwidth and latency

    Moderate: up to tens of megabits per second, low latency

    C3 Wires

    Clock, data out, data in, plus one chip-select per slave

    C4 Topology

    One master, several slaves sharing clock and data lines, each with its own select

    C5 Who builds each side

    Many vendors; no single standard, so each device's datasheet defines its commands (fact S11)

    Selection is by a dedicated wire per slave, not by address; only the selected slave drives the shared return line.

    SPI's answers to the fifteen questions

    Each answer links to the lesson that explains the idea behind it.

    #

    Question

    Answer

    1

    When is the data valid?

    The master drives SCLK; data is sampled on one clock edge and changed on the other, chosen by the mode (CPOL, CPHA) (1.1)

    2

    Where does a message start and end?

    Chip-select low brackets a transaction; inside it, framing is by bit count as each device defines (2.2)

    3

    Is the receiver ready?

    None: the master clocks whenever it wants; the slave must keep up (push, valid-only) (3.6)

    4

    How much may I send before I hear back?

    None in the protocol; the master paces everything with the clock, and devices that need time use status polling defined in their datasheet (4.1)

    5

    What exactly is being asked?

    Commands, addresses and data are device-specific, defined by each datasheet; SPI only shifts bits (5.4)

    6

    How many requests can be in flight?

    One transaction at a time per bus; full duplex shifting both ways at once (6.1)

    7

    In what order do results become visible?

    Bits and bytes arrive in the order shifted (7.1)

    8

    Who gets the wire?

    The master decides: one chip-select at a time, no arbitration (only one master) (8.1)

    9

    Why can it hang?

    Nothing waits for a response, so no deadlock; an absent or busy slave is simply not noticed (9.1)

    10

    What if bits go wrong?

    No detection or correction in the protocol; some devices add CRCs or status bits of their own (10.1)

    11

    How do the two sides agree at start-up?

    No discovery: the master must know each slave's mode, speed and commands in advance (11.5)

    12

    How do we save power without losing data?

    Not addressed by the protocol; deselected devices are idle, and many enter low-power states defined in their datasheets

    13

    What if there are several copies of one value?

    Not applicable

    14

    Who is allowed to ask?

    Not addressed: access is by physical wiring

    15

    How do we know it is correct?

    No compliance programme; verification follows each device's datasheet timing and command set (15.8)

    The choices that define SPI

    • Master-driven clock: the master sets the pace, so there is no clock recovery and the slave needs no clock of its own.

    • Selection by wire: one chip-select per slave instead of addresses, trading pins for simplicity.

    • No acknowledgement: the fastest possible exchange, at the price of never knowing whether anyone listened.

    • Four modes: clock polarity and phase are configuration both sides must agree on.

    What breaks

    A design (illustrative) connected a sensor configured for SPI mode 3 to a master running mode 0. The master sampled on the edge where the sensor was changing data, and readings were occasionally off by one bit position. Nothing reported an error, because SPI has no checks. Setting both sides to the same CPOL and CPHA fixed it; the datasheet had specified the mode all along.

    Why this matters

    Senior lens. SPI is the template for "one master, simple slaves, short distance": everything is decided by the master and the datasheets, nothing by negotiation or acknowledgement. When reviewing an SPI design, check the mode, the clock rate against every slave's limit, what happens when a slave is absent (all ones or zeros read as data), and whether any device needs status polling.

    Interview

    Asked: "What does SPI not do that I2C does?"

    Weak answer: It's the same but faster.

    Strong answer: SPI has no addressing, no acknowledgement and no arbitration. Slaves are selected by a dedicated chip-select wire each, so there's nothing to arbitrate with one master; nothing acknowledges a byte, so a missing slave just reads as all ones; and it has no clock stretching, so the slave must keep up with the master's clock. In exchange it is full duplex, uses push-pull drivers that run much faster than I2C's open-drain lines, and is trivially simple. Both sides must agree the mode, CPOL and CPHA, in advance.

    Follow-ups: (1) How does the master know a slave is present? (2) What is CPHA?

    Check yourself Why does SPI need no arbitration?

    There is one master, and it selects exactly one slave with its chip-select.

    Check yourself A slave is unplugged. What does the master read?

    Whatever the undriven MISO line floats or is pulled to, typically all ones; SPI cannot tell.

    Key takeaways

    • SPI: master-driven clock, one chip-select per slave, full-duplex shifting, no acknowledgement.

    • Modes (CPOL, CPHA), commands and speeds are agreed in advance from datasheets.

    • It is fast and simple because it checks nothing; absent or confused slaves go unnoticed.

    Keep going

    Next: Lesson 16.4, I2C. Two wires, many masters, an acknowledgement for every byte.

    Related topics

    • Part 16 overview: Protocols Dissected

    Previous

    209 / 234

    Next: I2C

    Up next

    Up nextI2C

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • How to Dissect a Protocol
    • APB
    • AHB