Dans le FPGA Zynq : comment la carte de contrôle d’un Antminer parle à ses hashboards

Ouvrez n’importe quelle carte de contrôle d’Antminer de l’ère S9 à S19 : la plus grosse puce n’est pas qu’un processeur — c’est un Xilinx Zynq, un composant hybride qui réunit deux cœurs ARM Cortex-A9 et une matrice FPGA sur la même puce. La plupart des mineurs n’y pensent jamais. C’est pourtant grâce à ce FPGA que le mineur peut alimenter des centaines de puces ASIC à la vitesse du matériel, et il explique plusieurs mystères de réparation : pourquoi certaines pannes survivent à un reflash du firmware, pourquoi certains registres comptent, et pourquoi les cartes plus récentes fonctionnent tout autrement.

Voici une visite guidée, en langage clair, du chemin de données entre la carte de contrôle et les hashboards — fondée sur notre travail d’atelier et sur les projets open-source qui ont documenté cette architecture, au premier chef braiins/zynq-io (le design FPGA ouvert de Braiins) et polprog/antminer_zynq.

La division du travail : le CPU décide, le FPGA transmet

Sur une carte Zynq, le CPU ne parle jamais directement aux puces de hachage. Le flux ressemble à ceci :

CPU → bus AXI → FIFOs de travail/commande du FPGA → UART TX/RX → chaîne de puces du hashboard

Le logiciel de minage (bmminer/cgminer) prépare le travail et l’écrit, via le bus AXI, dans des FIFOs implantés dans la matrice FPGA. Le FPGA cadence ensuite ce travail sur des lignes UART — à travers des convertisseurs de niveau, sur les broches 11 et 12 de chaque câble de données à 18 broches — vers les puces ASIC chaînées de chaque hashboard. Les réponses (les nonces) reviennent par le même chemin. L’espace de registres du FPGA se trouve à l’adresse de base 0x43C00000.

Le FPGA ne fait pas que pelleter du travail. Il génère aussi le signal VID du contrôle de tension, pilote les sorties PWM des ventilateurs, gère les GPIO et les bus I2C partagés avec les hashboards, et embarque des moteurs CRC pour que les contrôles d’intégrité ne consomment pas de cycles CPU.

Les deux modules noyau qui font le pont

L’espace utilisateur Linux atteint le FPGA par deux petits modules noyau chargés au démarrage par /etc/init.d/S10modules :

• bitmain_axi.ko crée /dev/axi_fpga_dev, qui expose les registres de contrôle et d’état du FPGA au démon de minage.
• fpga_mem_driver.ko crée /dev/fpga_mem et alloue un tampon DMA de 16 Mo pour les données de travail et de nonces (à l’offset mémoire 0x0F000000 sur les systèmes à 256 Mo).

Si ces modules ne se chargent pas, le mineur démarre, l’interface web répond — et le hashrate reste à zéro, car le logiciel n’a plus aucun chemin vers le FPGA. C’est une des signatures de panne à connaître quand on lit les kernel logs.

Pourquoi le bitstream est irremplaçable

La configuration du FPGA — le fichier bitstream soc_system.rbf — se charge tôt dans le démarrage depuis BOOT.bin et est vérifiée par RSA contre des clés gravées dans les eFuses du SoC. Sur une carte verrouillée, impossible d’y substituer votre propre design FPGA; la chaîne de vérification que nous avons cartographiée dans notre guide de la chaîne de démarrage NAND le protège de bout en bout. Les firmwares tiers cohabitent avec le bitstream d’origine et remplacent les parties du système qui ne sont contrôlées que par SHA256.

Une note historique qui mérite d’être créditée : Braiins a publié son design FPGA Zynq en open source. Leur design générique pour carte de développement utilisait le SPI, tandis que le design de minage du S9 utilise des blocs IP UART — un détail qui compte si vous lisez ce code en vous attendant à une correspondance exacte avec les cartes de production.

La preuve que le logiciel suffit : BBB et Amlogic

Voici le rebondissement intéressant pour qui croit le FPGA irremplaçable : Bitmain lui-même a livré des cartes de contrôle qui n’en ont pas. Les cartes BeagleBone (TI AM335x, S19j/S19j Pro de fin 2021) et les cartes Amlogic A113D (S19 récents, S19 XP, S21, T21) pilotent les hashboards en UART logiciel — sans aucun FPGA. Sur les cartes Amlogic, chaque hashboard reçoit son propre périphérique série (/dev/ttyS1 à /dev/ttyS3) avec ses GPIO de réinitialisation et de détection, le bloc d’alimentation répond sur I2C à l’adresse 0x10, et les ventilateurs dépendent de deux canaux PWM — le tout documenté dans skot/amlogic-cb-tools.

Le compromis est simple : matériel et firmware plus simples, mais le CPU porte la charge de communication que le FPGA absorbait. Savoir quelle architecture vous tenez en main est la première étape du diagnostic — notre référence des cartes de contrôle couvre l’identification, et l’histoire du verrou Amlogic explique la couche de verrouillage ajoutée sur les cartes les plus récentes.

Ce que ça change à l’atelier

Trois leçons pratiques. Un : une carte qui démarre proprement mais affiche zéro hashrate avec des hashboards sains mérite un examen du chemin FPGA — modules chargés? périphériques présents? — avant que quiconque ne sorte la station de refusion. Deux : les pannes de la matrice FPGA ou de ses rails d’alimentation sont des réparations au niveau de la carte, pas des problèmes de firmware; aucune image ne les fera disparaître. Trois : sur les cartes sans FPGA, les mêmes symptômes changent de sens — périphériques série et GPIO remplacent FIFOs et registres AXI comme premiers suspects.

Si une carte de contrôle vous résiste, c’est du travail d’atelier que nous faisons chaque semaine — réparation ASIC à Montréal, cartes de contrôle comprises. Et pour aller plus loin dans l’architecture, les dépôts open-source ci-dessus sont la carte sur laquelle nous nous appuyons tous.