Hashboard vs Control Board: ASIC Anatomy

A Bitmain-style ASIC, Antminer family and relatives, is an assembly of distinct roles: hashboards that produce hashrate, a control board that orchestrates work, a power supply, and an airflow or fluid path. Mixing up those roles gets the wrong part ordered: you swap a controller when the bus is dead, or blame firmware when a board simply does not answer.

What a hashboard does

A hashboard carries the ASICs, the chips wired for Bitcoin's SHA-256 proof-of-work, along with local power stages, sensors, and the thermal hardware. This is where electrical energy becomes heat and hash trials.

The board does not choose the pool. It receives jobs, rolls nonces and header variants, then reports shares, errors, and temperatures. Several boards work in parallel in one chassis, and a silent board does not necessarily stop the others: total hashrate drops by a fraction close to the count of dead boards, without yielding a universal percentage, since revisions and firmware both weigh on the result.

Failures are physical or electrical: a dead ASIC, an open trace, an oxidized connector, poor mechanical seating, local overheating, a collapsing board rail. Firmware can hide or amplify the symptom, with statuses like dead, missing, or unbalanced.

What the control board does

The control board is a small embedded computer: Linux, web UI, a pool client that is usually Stratum, a clock, Ethernet, and buses to the hashboards, the PSU, and the fans. It authenticates to the pool, slices the work, collects and submits shares, reads sensors, drives fan setpoints according to firmware, and exposes telemetry.

Two practical consequences. If it reboots, all boards stop mining for the length of that boot, however healthy they are. If its network drops, boards can keep hashing a stale job, and the pool will see stales or silence rather than a silicon fault.

It does not carry the heavy current and draws little compared with the boards. Replacing it therefore fixes neither a weak power rail nor a burned ASIC.

How they talk

The usual link is a serial bus, often described as UART or chain, alongside power and ground. The exact protocol depends on the generation and does not need reimplementing by the operator. The path is fragile, though: a ribbon not fully seated, a bent pin, interference, or firmware that does not speak that board revision.

An invisible board can therefore be dead, under-powered, badly connected, or simply unrecognized by this control image. Conversely, a faulty control board can make three healthy boards look dead.

Diagnose by role

Before ordering a part, work down this grid:

1. Does the machine have an IP, a reachable interface, an uptime that advances? If not, look at the controller, the network, or its power, not at hash silicon.
2. Does the interface see all boards, with one flagged in fault? Isolate that board, by reseating it, moving it if the chassis allows, or testing it on a known-good controller, before declaring it dead.
3. Do all boards drop together, often with a reboot? Look at the PSU, hall thermals, or a controller crash.
4. Do shares leave the box while pool hashrate is zero or sawtooth? The problem sits on the control side: pool, DNS, firewall, clock.

The grid fits in one sentence: the hashboard hashes, the controller decides and talks.

Compatibility across generations

A board of a given revision is not guaranteed compatible with any control board, even when the connector fits mechanically. For pinout and compatibility, the only source that binds is the model documentation the vendor published, on bitmain.com and its support site. Without a document for that specific board and controller pair, treat compatibility as unestablished and test before buying in volume.