System Bus

A system bus is the communication pathway that ties a processor together with memory and peripherals, carrying the data, addresses, and control signals that let those parts operate as one machine. Every controller board — from a desktop motherboard to the compact SoC board running an ASIC miner — is organised around one or more buses, and understanding the bus structure is what turns a board from a mysterious slab into a map you can diagnose.

The three logical buses

A classic bus is described as three cooperating parts. The data bus carries the actual values being read or written. The address bus selects which memory location or device register the transfer targets, and its width sets how much address space the processor can reach. The control bus carries the timing and command signals — read, write, clock, interrupt lines — that keep every component in step. Together they let the CPU place an address, assert a read, and receive data back over a single coordinated path. Modern on-chip designs implement the same three roles even when the wires are buried inside a package rather than visible as motherboard traces.

Parallel versus serial

Older buses were parallel, moving many bits simultaneously across separate wires. As clock speeds rose, timing skew and crosstalk between those parallel lines became the limiting factor, so modern systems increasingly favour high-speed serial links that send fewer bits at a time but clock far faster — PCI Express being the canonical example. Meanwhile, low-speed device communication settled on simple serial buses that trade speed for pin count and simplicity: SPI for flash memory and fast peripherals, I2C for sensors and configuration devices, and point-to-point UART links for consoles and inter-board communication.

The bus map of an ASIC miner

A miner control board is a tidy illustration of bus hierarchy. On a Zynq-based Antminer board, the dual Cortex-A9 cores talk to on-chip peripherals and the FPGA fabric over the AXI bus — the SoC's internal system bus — with the FPGA's registers mapped into the processor's address space like any other memory. From there, the buses fan out by role: the SoC reaches its NAND flash and DDR3 over dedicated memory interfaces, while I2C buses reach the temperature sensors, EEPROMs, and PIC controllers on the hashboards, and UART channels — generated by FPGA logic rather than the CPU's own serial ports — carry work and nonces to the hash chip chains. Notably, there is no wide parallel highway to the hashboards: each 18-pin connector carries a handful of serial signals, which is why a whole hashboard can be diagnosed by probing just a few lines. Other control board generations (BeagleBone-based, Amlogic-based) drop the FPGA and drive the same serial buses directly from the CPU, proving the architecture is about roles, not specific silicon.

Why the concept matters on the bench

Bus thinking is diagnostic thinking. When a board misbehaves, the question "which bus is this device on, and is that bus alive?" narrows the search immediately: a dead I2C bus takes out every sensor on it at once, a single unresponsive device suggests the device or its chip select rather than the bus, and garbage on a console points at the UART's clocking rather than the CPU. A logic analyzer on the relevant bus turns guesswork into observation. Learn the bus map of the boards you service and every fault becomes an address on that map rather than a mystery.

It also explains why control boards are the most interchangeable part of a miner: as long as replacement hardware speaks the same buses to the hashboards — the same serial signalling, the same sensor and EEPROM protocols — the silicon behind them is negotiable. The bus is the contract; everything else is implementation.