SPI (Serial Peripheral Interface)

SPI (Serial Peripheral Interface) is a synchronous serial bus that a controller chip uses to exchange data with one or more peripheral chips on the same board. It is full-duplex, meaning data can move in both directions at once, and it is fast and simple to implement, which is why it shows up everywhere inside ASIC miner control boards and the small accessory boards around them. Where a network connects machines, SPI is one of the little buses that connect the chips inside a machine.

The four signal lines

A standard SPI connection uses four logic signals. SCLK is the serial clock, driven by the controller so both sides stay in lock-step. MOSI (controller-out, peripheral-in) carries data from the controller to the peripheral, and MISO carries data back the other way — simultaneously, which is what makes the bus full-duplex. The fourth line, chip select (labelled SS or CS, and active-low on nearly everything), tells a specific peripheral that the bus is talking to it; multiple peripherals share the clock and data lines but each gets its own select. Because the controller supplies the clock, there is no agreed baud rate to negotiate the way an asynchronous UART link needs one; the clock speed is simply whatever the controller sets, from a few hundred kilohertz to tens of megahertz depending on the parts and trace lengths involved. The one configuration trap is SPI mode — clock polarity and phase come in four combinations, and a mismatch yields garbage data on a bus that otherwise looks perfectly healthy on a scope.

Where it appears in mining hardware

Inside a typical control board you will find SPI driving the flash memory that holds firmware and boot code, configuration EEPROMs, displays, and sometimes the ADCs that monitor board health. The Zynq SoC on classic Antminer control boards exposes two SPI controllers among its peripherals, alongside its UARTs and I2C buses. Worth knowing for accuracy's sake: the hashboards themselves are not SPI devices — Antminer control boards talk to the ASIC chain over UART (on Zynq boards, through FPGA-managed UART FIFOs), with I2C handling sensors and the PIC on models that have one. SPI's territory is the memory and housekeeping chips on the control board itself.

On the repair bench

When you read or reprogram a flash chip with an external programmer during a repair — dumping a bricked board's NAND companion NOR chip, or writing a clean bootloader — you are usually clocking it out over SPI, either in-circuit with a test clip or after lifting the chip. Its main design trade-off is wiring: every extra peripheral needs its own chip-select line, so SPI scales in throughput but not in pin count the way a two-wire bus does. That is exactly the division of labour on a control board: SPI for the fast memory parts, I2C for the slow sensor crowd.

Faster variants on the same idea

The flash chips on modern boards often extend the basic bus to dual or quad SPI, using two or four data lines in parallel to multiply read throughput — that is what a "QSPI flash" marking means, and it is why a programmer that speaks plain SPI can still usually read such a chip in its single-bit compatibility mode, just more slowly. Bench work adds one more practical caution: reading a flash chip in-circuit with a test clip powers the chip through the clip, and everything else sharing its supply rail may wake up and fight you for the bus. If an in-circuit dump returns inconsistent data across attempts, that contention is the usual reason, and lifting the chip for an out-of-circuit read is the reliable fix.

For the addressing line in practice, see chip select. For the slower two-wire alternative used for sensors and power management, see I2C bus, and compare the system bus for the bigger picture.