Des puces qu’on peut recâbler
Le minage FPGA expliqué, du Spartan-6 au VU9P
Pourquoi une carte USB de 25 watts datant de 2011 mine encore, pourquoi une carte de datacenter de 2016 peut faire rougir une carte graphique flambant neuve, pourquoi chaque ASIC commence sa vie sur l’une d’elles, et pourquoi votre rig Monero peut dormir sur ses deux oreilles. Thé recommandé ; fer à souder facultatif.
Un FPGA est une puce dont on peut réécrire le câblage. Chargez-y le bon bitstream et elle cesse d’être un composant à tout faire pour devenir une machine à hacher, et rien d’autre. Sur les algorithmes de pur calcul comme BLAKE2b (Proxima), SHA-3 ou SHA-256, c’est redoutablement efficace : une carte VU9P en 16 nm fait environ 10 GH/s à 240 W sur Proxima, soit à peu près deux fois plus de hashs par watt qu’une RTX 5090, pourtant gravée trois générations plus tard. Notre bitstream ZTEX Spartan-6 est désormais open source et tourne à environ 124 MH/s pour 25 W par carte quadruple. Mais les FPGA ont peu de mémoire : sur les algorithmes memory-hard, les GPU l’emportent, et sur RandomX, c’est un banal CPU de bureau qui gagne. À chaque tâche son outil.
Chapitre I : Une petite dispute sur Discord
Tout a commencé, comme souvent dans la crypto, sur un salon de discussion. Nous venions de publier notre bitstream FPGA pour Proxima, et quelqu’un a posé une question parfaitement légitime : « Un GPU, ce n’est pas tout simplement bien meilleur et plus efficace ? » Un autre a avoué n’avoir jamais possédé de FPGA et trouver tout cela affreusement compliqué.
Deux remarques justes, qui méritent une vraie réponse plutôt qu’une ligne glissée entre deux pavés sur la publicité des pools. La voici donc : ce que sont ces bestioles, d’où elles viennent, pourquoi elles peuvent être si efficaces et, tout aussi important, dans quels cas elles ne sont absolument pas le bon outil. Nous tâcherons de tenir le jargon en laisse courte.
Ceci est un article d’explication, pas une liste de courses. Si vous avez déjà des cartes FPGA au fond d’un tiroir, il leur reste peut-être de beaux jours. Sinon, ne vous précipitez pas, s’il vous plaît, pour en acheter une palette sur la foi d’un article de blog. La rentabilité dépend du cours de la cryptomonnaie, de la difficulté, de votre prix de l’électricité et du marché de l’occasion, et nous préférerions ne pas nous faire sermonner par votre comptable.
Chapitre II : Mais au fait, qu’est-ce qu’un FPGA ?
FPGA signifie Field-Programmable Gate Array, que l’on traduit par « réseau de portes programmable in situ ». Une fois déballé, c’est assez littéral : une matrice de portes logiques que l’on peut programmer « sur le terrain », c’est-à-dire après que la puce a quitté l’usine.
Un CPU ou un GPU est un circuit figé qui exécute du logiciel : il va chercher les instructions l’une après l’autre et les exécute. Un FPGA, lui, n’exécute aucune instruction. C’est une immense grille de petites briques avec, entre elles, un central téléphonique programmable, et c’est vous qui décidez comment les briques sont reliées. Une fois le câblage fait, les données traversent simplement le circuit que vous avez construit.
Les briques en question sont :
- Les tables de correspondance (LUT) : de minuscules mémoires capables d’imiter n’importe quelle fonction logique à quelques entrées. Un ET, un OU exclusif, un morceau d’additionneur : une LUT jouera volontiers n’importe lequel de ces rôles.
- Les bascules (flip-flops) : des cellules de stockage d’un bit qui conservent un résultat d’un coup d’horloge au suivant. Ce sont elles qui permettent de construire des pipelines.
- Les blocs DSP : des multiplieurs et additionneurs câblés en dur pour l’arithmétique lourde.
- La Block RAM (et, sur les puces récentes, l’UltraRAM) : de petites mémoires intégrées à la puce, quelques mégaoctets sur un modèle de milieu de gamme et quelques dizaines de mégaoctets sur un gros. Retenez ce chiffre : il aura son importance plus loin.
- Le routage : le câblage programmable qui relie tout ce qui précède. Sur un gros FPGA, le routage occupe davantage de silicium que la logique elle-même.
Et le bitstream ?
Le bitstream est le fichier qui règle chacun de ces commutateurs. Vous décrivez votre circuit dans un langage de description matérielle comme Verilog ou VHDL. Les outils du fabricant le synthétisent ensuite en LUT et en bascules, placent chaque élément quelque part sur la puce, routent les fils entre eux, puis vérifient enfin que chaque signal arrive à temps pour le coup d’horloge suivant. Cette dernière étape s’appelle la fermeture temporelle (timing closure), et c’est là que les ingénieurs FPGA prennent des rides à vue d’œil.
Chargez le bitstream (par USB sur une carte ZTEX, par JTAG sur une carte VU9P) et une puce vierge devient, par exemple, une rangée de cœurs BLAKE2b. Chargez-en un autre et la même puce devient un mineur SHA-3, un encodeur vidéo ou un filtre radar. C’est l’équivalent électronique d’un Meccano qui se remonte tout seul en moins d’une minute.
À quoi servent normalement les FPGA ?
Le minage n’est qu’un numéro de foire. Leurs vrais métiers sont bien plus respectables :
- Télécoms : stations de base mobiles et commutateurs réseau, là où les normes évoluent plus vite qu’on ne peut graver une puce.
- Trading haute fréquence : quand les nanosecondes valent de l’argent, on met la logique de trading directement sur la carte réseau.
- Aérospatiale et défense : radars, satellites et avionique, où les petits volumes rendent les puces sur mesure non rentables.
- Test et mesure : les entrailles des oscilloscopes et des analyseurs logiques.
- Accélération en datacenter : Microsoft a, chose célèbre, installé des FPGA dans ses serveurs pour accélérer Bing, et Amazon loue des puces VU9P à l’heure sous forme d’instances EC2 F1. Oui, la même famille de puces que celle sur laquelle nous minons Proxima.
- Rétro-gaming : des projets comme MiSTer recréent d’anciennes consoles et d’anciens ordinateurs familiaux en matériel au lieu de les émuler en logiciel. Votre Commodore 64 vit toujours, en portes logiques.
- La conception d’ASIC, qui mérite un chapitre à elle seule.
Chapitre III : Chaque ASIC commence sa vie sur un FPGA
Un ASIC (Application-Specific Integrated Circuit, circuit intégré spécifique à une application) est une puce conçue pour faire une seule chose. Un ASIC Bitcoin fait du SHA-256 et absolument rien d’autre, et c’est précisément pour cela qu’il y excelle. Le hic, c’est ce qu’il en coûte d’y arriver. Un tape-out moderne, ce sont des photomasques, des séries d’ingénierie et des mois de fonderie, pour un total de plusieurs millions de dollars sur un procédé de pointe ; et s’il y a un bug dans le silicium, vous avez le plaisir de tout repayer.
Aucune personne sensée n’envoie donc un design en fonderie sans l’avoir testé. Le même code Verilog qui deviendra l’ASIC tourne d’abord sur des FPGA : sur une seule carte pour un petit design, ou sur d’immenses baies remplies de FPGA pour un processeur de smartphone. Les grands éditeurs de conception de puces vendent des systèmes complets de « prototypage » et d’émulation construits à base de FPGA précisément dans ce but. On trouve les bugs au prix du FPGA plutôt qu’au prix de la fonderie, et l’équipe logicielle peut commencer à écrire les pilotes des mois avant que le vrai silicium n’existe.
Le matériel de minage a suivi exactement ce chemin. Les cœurs SHA-256 qui tournaient sur FPGA en 2011 et 2012 étaient, dans l’esprit et souvent jusque dans le code source, les prototypes des premiers ASIC Bitcoin. Butterfly Labs vendait des mineurs FPGA avant ses ASIC ; les designs d’amateurs ont validé le pipeline, puis les fabricants d’ASIC l’ont « figé » dans le silicium.
- Recâblable en moins d’une minute
- Disponible dans le commerce, pas besoin de fonderie
- Paie sa flexibilité : routage et LUT coûtent en surface, en consommation et en fréquence
- Nouvel algorithme ? Nouveau bitstream.
- Câblé une fois pour toutes
- Des millions d’investissement initial, des mois de délai
- Aucune taxe de flexibilité : on cite couramment un gain de 10 à 30× sur un FPGA en surface et en consommation
- Nouvel algorithme ? Nouveau presse-papiers.
Cette « taxe de flexibilité » est bien documentée dans la littérature académique : les mesures classiques attribuent à un FPGA, très grossièrement, 20 à 35× la surface de silicium, environ 10 à 15× la consommation dynamique et une lenteur de 3 à 4× par rapport au même circuit réalisé en ASIC. D’où la question évidente : si les FPGA paient une taxe aussi lourde, comment diable peuvent-ils battre les GPU ?
Chapitre IV : Pourquoi un bon bitstream bat un GPU par watt
Parce qu’un GPU paie lui aussi une taxe, et que sur le bon algorithme, elle est encore plus lourde.
Un GPU est un magnifique ordinateur parallèle généraliste. À chaque cycle, chacun de ses dizaines de milliers de cœurs va chercher une instruction, la décode, la planifie, lit ses opérandes dans un banc de registres, effectue le calcul proprement dit, puis réécrit le résultat. Seule cette étape-là, le calcul proprement dit, relève du hachage. Tout le reste est du surcoût, et déplacer des données vers et depuis les registres et les caches coûte bien plus d’énergie que l’arithmétique elle-même. Un GPU, c’est un orchestre symphonique obligé de lire toute la partition à voix haute avant de jouer chaque note.
Un mineur sur FPGA, lui, n’a aucune instruction à aller chercher. La fonction de hachage est le circuit. Chaque tour de l’algorithme devient un étage de logique physique, les étages sont enchaînés en un pipeline, et à chaque coup d’horloge un nouveau nonce entre d’un côté pendant qu’un hash terminé sort de l’autre. Pas de décodage d’instructions, pas d’ordonnanceur, pas de va-et-vient avec un banc de registres : juste des données qui circulent à travers des portes.
L’exemple de BLAKE2b : quand le repas gratuit est une rotation gratuite
La preuve de travail de Proxima est BLAKE2b, et elle illustre magnifiquement la différence. BLAKE2b travaille sur des mots de 64 bits avec seulement trois opérations : l’addition, le OU exclusif (XOR) et la rotation de bits (de 32, 24, 16 et 63 bits). Voyons maintenant ce que chaque type de puce doit faire :
- Sur un GPU, les unités entières font 32 bits de large. Chaque addition 64 bits devient deux additions 32 bits plus la gestion de la retenue, et chaque rotation 64 bits devient une paire de décalages. Chacune est une instruction, et chaque instruction traîne le surcoût décrit plus haut.
- Sur un FPGA, un additionneur 64 bits est construit directement dans la matrice grâce aux chaînes de retenue dédiées de la puce. Et une rotation d’un nombre fixe de bits ne coûte strictement rien. Ce n’est pas un calcul : on branche simplement le fil 0 là où devrait aller le fil 24. Zéro logique, zéro watt, zéro cycle d’horloge. Quelque part, un GPU pleure en silence.
Ajoutez à cela qu’on peut dimensionner le circuit exactement à la tâche (pas de voies 32 bits pour faire un travail de 8 bits, pas d’unités de virgule flottante qui se tournent les pouces) et vous obtenez une puce où presque chaque transistor qui commute fait du hachage utile. Tout le secret est là.
Les chiffres, honnêtement
C’est ici qu’il faut être scrupuleusement équitable, car l’âge de la puce compte énormément. La finesse de gravure (le chiffre en « nm ») est de loin le facteur le plus déterminant pour l’efficacité énergétique, et nos FPGA ne sont plus de première jeunesse.
| Matériel (Proxima, BLAKE2b) | Gravure / lancement | Hashrate | Consommation | Efficacité |
|---|---|---|---|---|
| ZTEX 1.15y, 4× Spartan-6 LX150 | 45 nm / puce de 2009 | ~124 MH/s | ~25 W | ~5 MH/J |
| NVIDIA RTX 5090 | classe 4 nm / 2025 | ~12 GH/s | ~600 W | ~20 MH/J |
| BCU1525, Virtex UltraScale+ VU9P | 16 nm / puce de 2016 | ~10 GH/s | ~240 W | ~42 MH/J |
Nos propres mesures avec ProxiChorizo (GPU) et suprminer-fpga (FPGA). Le chiffre ZTEX correspond au bitstream à 124 MHz ; la démonstration à 100 MHz fournie avec le logiciel fait environ 100 MH/s. MH/J = mégahashs par joule, c’est-à-dire par watt-seconde.
Lisez ce tableau attentivement, car il dit deux choses différentes.
D’abord, la vieille carte Spartan-6 n’est pas plus efficace qu’un GPU moderne. Elle fait environ un quart des hashs par watt de la 5090. Mais voyez ce qu’elle est : une puce en 45 nm conçue en 2009, avec quatre ou cinq générations de gravure de retard, et elle reste à moins d’un facteur quatre du vaisseau amiral actuel de NVIDIA. C’est comme une Mini des années 1960 qui tiendrait tête à une citadine moderne en consommation. Elle ne gagne pas, mais elle ne devrait même pas être sur la ligne de départ. En prime, elle consomme 25 W, s’alimente en USB, reste silencieuse sur son étagère et ne réclame ni alimentation de 1 000 W ni permis de chauffage d’appoint.
Ensuite, un FPGA moderne bat purement et simplement le GPU. Le VU9P a lui-même dix ans et trois générations de gravure de retard sur la 5090, et pourtant il fournit environ deux fois plus de hashs par watt. Placez les deux sur le même nœud de gravure et l’écart serait plus large encore. C’est l’avantage architectural, tout bonnement, une fois que quelqu’un a fait le dur travail de construire un bitstream qui boucle sa fermeture temporelle à une fréquence correcte.
Sur un hash de pur calcul, un design FPGA bien conçu bat largement par watt un GPU de la même génération, et un ASIC bat les deux. Les vieux FPGA ne perdent face aux GPU récents que parce que le silicium a énormément progressé en quinze ans, pas parce que l’idée est mauvaise.
Chapitre V : Petite histoire, ou quand une étagère de cartes clignotantes régnait sur Bitcoin
2009–2010 : les CPU, puis les GPU
Bitcoin a d’abord été miné sur de simples CPU. En dix-huit mois environ, on s’est aperçu que les cartes graphiques étaient bien meilleures en SHA-256, et les Radeon HD 5870 et 5970 sont devenues les bêtes de somme, atteignant chacune quelques centaines de MH/s tout en faisant office de radiateurs plutôt efficaces.
2011 : l’arrivée du FPGA
En 2011, des designs SHA-256 open source pour FPGA ont commencé à apparaître sur BitcoinTalk, d’abord sur des cartes de développement, puis sur des cartes conçues spécialement pour le minage. La puce de loin la plus populaire était le Xilinx Spartan-6 LX150 : bon marché pour sa taille, riche en logique et sobre en consommation. La bonne puce au bon moment.
Il en est sorti une petite ménagerie de cartes dont les anciens parlent encore la larme à l’œil :
- ZTEX USB-FPGA 1.15x et 1.15y, venues d’Allemagne : un ou quatre LX150 avec un contrôleur USB, environ 210 MH/s par puce en SHA-256, soit à peu près 860 MH/s pour la 1.15y quadruple. Du plug-and-play pour l’époque, et la carte sur laquelle nous minons encore Proxima.
- Cairnsmore1, d’Enterpoint à Malvern, en Angleterre : une carte à quatre LX150 qui sortait environ 800 MH/s et pouvait être overclockée. Une carte de minage britannique, ce qui suffit à ce que nous la mentionnions avec une certaine fierté et un biscuit à la main.
- Icarus : un design open hardware chinois à deux LX150, environ 380 MH/s.
- X6500 : une autre carte à deux LX150, à environ 400 MH/s.
- La BFL Single de Butterfly Labs : environ 830 MH/s dans un boîtier doté d’un ventilateur qu’on entendait depuis le canton voisin.
Leur attrait, c’était l’efficacité. Une Radeon faisait environ 2 à 3 MH/J en SHA-256 ; une carte Spartan-6 tournait autour de 20. Dix fois plus de hashs pour la même électricité, un silence quasi total et pas d’incendie domestique. cgminer, puis BFGMiner, se sont dotés de pilotes pour la plupart de ces cartes, et pendant environ dix-huit mois glorieux, les mineurs sérieux étaient ceux qui avaient une étagère de cartes FPGA clignotantes.
2013 : la marée des ASIC
Puis, début 2013, les premiers ASIC Bitcoin ont été livrés. Avalon, les Block Erupters d’ASICMiner, et finalement les puces maintes fois retardées de Butterfly Labs elle-même : les cœurs SHA-256 des FPGA avaient été figés dans le silicium, et soudain une clé USB faisait le travail d’une carte FPGA entière. Exactement comme le prédit le chapitre III, le FPGA avait servi de prototype, et une fois l’ASIC arrivé, le prototype était devenu obsolète pour cet algorithme. Des milliers de cartes Spartan-6 ont fini dans des tiroirs, des greniers et quelques cabanes de jardin.
2017–2020 : les années gros calibre
Les FPGA sont revenus pour les altcoins, cette fois sous forme de matériel de datacenter. La vedette était le Xilinx Virtex UltraScale+ VU9P, un monstre en 16 nm d’environ 1,2 million de cellules logiques. On le trouvait dans les instances cloud F1 d’Amazon et, plus important pour les mineurs, sur des cartes PCIe comme la carte de développement VCU1525 et sa cousine taillée pour le minage, la BCU1525. Sont ensuite arrivées des puces encore plus grosses, comme le VU13P de la CVP-13 de Squirrel Research Labs.
Squirrel (SQRL) fabriquait aussi les sympathiques petites cartes Acorn : des FPGA Artix-7 sur cartes M.2, à glisser dans un emplacement libre. Toute une industrie artisanale s’est développée autour : des développeurs de bitstreams vendant des images d’algorithmes, souvent avec un dev fee, pour des cryptomonnaies dont l’algorithme n’avait pas encore d’ASIC. Certaines ont même pris le chemin inverse et ont été conçues délibérément pour les FPGA. L’Odocrypt de DigiByte change d’algorithme tous les dix jours, ce qu’un FPGA peut suivre avec un nouveau bitstream et qu’un ASIC ne peut pas.
2026 : on dépoussière les Spartan
Ce qui nous amène à aujourd’hui. Le passage de Proxima à BLAKE2b en novembre 2026 a produit exactement le genre d’algorithme qu’adorent les FPGA : de l’arithmétique 64 bits pure et aucune grosse mémoire. Nous avons donc construit des bitstreams, et nous avons publié le logiciel hôte et le bitstream de démonstration ZTEX sous le nom de suprminer-fpga. Des cartes de quinze ans, qui avaient gagné leur pain pour la dernière fois sur Bitcoin en 2012, minent à nouveau. Il y a là quelque chose d’assez merveilleux.
Chapitre VI : Quand le FPGA n’est pas le bon outil, première partie : la mémoire
Voici le hic, et il est de taille. Vous vous souvenez de la mémoire intégrée du chapitre II ? Un gros FPGA comme le VU9P en a quelques dizaines de mégaoctets. C’est largement assez pour l’état d’un hash. C’est désespérément insuffisant pour un algorithme memory-hard.
Les algorithmes memory-hard sont conçus pour que chaque hash nécessite beaucoup de données qu’on ne peut pas calculer à la volée et qu’il faut donc aller chercher. Ethash (l’ancien algorithme d’Ethereum), KawPoW (Ravencoin), Autolykos et les différents hashs à base de DAG comme celui de Keryx travaillent sur un jeu de données de plusieurs gigaoctets, en lisant sans cesse à des endroits aléatoires (nous avons écrit tout un article d’explication sur les DAG si le cœur vous en dit). Sur ces algorithmes, la vitesse est déterminée par la bande passante mémoire, pas par la logique.
Or la bande passante mémoire est justement la chose qu’un GPU de jeu possède en quantité indécente. Une carte haut de gamme moderne fait transiter bien plus d’un téraoctet par seconde dans sa mémoire GDDR. La matrice d’un FPGA peut être aussi astucieuse qu’elle veut : si elle reste à attendre les données, elle ne hache pas.
« Et les cartes FPGA avec de la mémoire, alors ? »
Bonne question, et l’industrie a essayé. Certaines cartes ont ajouté de la DDR4 (trop lente pour ce travail), et les tentatives sérieuses ont misé sur la HBM, la mémoire empilée à haute bande passante des accélérateurs de datacenter : des cartes construites autour de puces Virtex équipées de HBM et les cartes Alveo HBM de Xilinx elle-même. Elles pouvaient miner l’Ethash, et certaines le faisaient honorablement. Mais avec quelques centaines de gigaoctets par seconde de bande passante et un prix à plusieurs milliers, elles n’allaient jamais faire rougir un GPU, qui apporte un téraoctet par seconde pour une fraction du prix et peut ensuite être revendu à un gamer. Sur un algorithme limité par la mémoire, la logique astucieuse du FPGA, c’est un moteur de Formule 1 branché sur un tuyau d’arrosage.
Pas de grosse mémoire, beaucoup d’arithmétique (SHA-256, SHA-3/Keccak, BLAKE2b, BLAKE3, Groestl) : territoire du FPGA, puis de l’ASIC dès qu’il y a assez d’argent en jeu. Des gigaoctets de lectures mémoire aléatoires (Ethash, KawPoW, Autolykos, hashs à base de DAG) : territoire du GPU.
Chapitre VII : Quand le FPGA n’est pas le bon outil, deuxième partie : RandomX et les cryptomonnaies CPU
Viennent ensuite les algorithmes conçus de A à Z pour un type de puce bien particulier : celle qui se trouve déjà dans votre ordinateur. Le plus connu est RandomX, utilisé par Monero depuis 2019.
RandomX ne hache pas au sens habituel du terme. Pour chaque hash, il génère un programme aléatoire et l’exécute dans une machine virtuelle. Ces programmes utilisent de l’arithmétique entière et en virgule flottante, y compris des calculs en double précision avec différents modes d’arrondi, ainsi que des branchements et des instructions AES. Ils lisent et écrivent dans un scratchpad dimensionné pour tenir pile dans les caches d’un CPU, et puisent des données dans un jeu de données de 2 Gio. Chacun de ces choix est délibéré. Les concepteurs de RandomX ont voulu que l’« ASIC RandomX idéal » ressemble trait pour trait à un CPU moderne, avec ses prédicteurs de branchement, son exécution dans le désordre, ses gros caches et sa virgule flottante rapide.
Que devrait donc faire un FPGA ? En substance, construire un CPU à partir de LUT et de bascules. Les processeurs « soft » sur FPGA existent, mais ils tournent à quelques centaines de mégahertz, tandis que la puce de votre ordinateur de bureau tourne à quatre ou cinq gigahertz avec des décennies de microarchitecture derrière elle. C’est comme vouloir battre une Rolls-Royce avec une voiture en kit à monter soi-même : techniquement, on peut la construire, mais on se fera doubler dès la bretelle d’accès.
Voilà pourquoi les FPGA ne jouent pratiquement aucun rôle dans le minage de Monero, et pourquoi les CPU y restent le bon outil. Il en va plus ou moins de même pour les autres algorithmes orientés CPU. Notre guide du minage CPU en donne la liste actuelle.
| Type d’algorithme | Exemples | Meilleur outil | Verdict FPGA |
|---|---|---|---|
| Limité par le calcul, simple | SHA-256, SHA-3, BLAKE2b (Proxima), BLAKE3, Groestl | ASIC > FPGA > GPU | Excellent |
| Algorithme changeant | Odocrypt | FPGA | Conçu pour lui |
| Memory-hard (jeu de données de plusieurs Go) | Ethash, KawPoW, Autolykos, hashs à base de DAG | GPU | Possible avec HBM, rarement rentable |
| Orienté CPU, code aléatoire | RandomX (Monero) | CPU | Pas rentable |
Chapitre VIII : « Ça a l’air compliqué », ou : vraiment ?
Il y a dix ans, honnêtement, oui. Aujourd’hui, beaucoup moins, du moins sur les cartes ZTEX. La ZTEX 1.15y possède son propre contrôleur USB, si bien que toute la procédure se résume à :
- Brancher la carte en USB et sur l’alimentation. Pas de riser PCIe, pas d’alimentation de 1 000 W, pas de réglages BIOS.
- Compiler suprminer-fpga (c’est un projet CMake classique pour Linux, et le README vous guide pas à pas).
- Le lancer une fois avec
--program --selftest. Il charge le bitstream dans les quatre FPGA et vérifie chaque cœur à l’aide de réponses connues. - Le pointer vers une pool et miner.
# programmer toutes les cartes ZTEX connectées et lancer l'autotest intégré
./suprminer-fpga -a proxima --fpga ztex --program --selftest
# miner Proxima (remplacez les valeurs génériques par vos propres informations)
./suprminer-fpga -a proxima --fpga ztex --account my-account.json \
--worker rig1 -o stratum+tcp://POOL:PORT
Chaque résultat signalé par le FPGA est re-haché par l’hôte avant d’être soumis, si bien qu’une carte capricieuse apparaît comme une erreur matérielle dans le journal plutôt que sous forme de shares rejetées. Le mineur fonctionne sur proxi.suprnova.cc et sur toute autre pool qui implémente le stratum ouvert de Suprnova.
Les cartes VU9P relèvent davantage du projet de bricoleur : ce sont des cartes PCIe, elles ont donc besoin d’une machine hôte, d’un vrai refroidissement et d’une programmation par JTAG, et la tension du cœur doit être réglée avant de charger le bitstream. Le mineur s’occupe de l’essentiel, mais ce n’est pas du « je branche et je file au pub ». Des images ZTEX plus rapides (dont celle à 124 MHz) et des bitstreams VU9P sont disponibles sur demande ; voir le dépôt.
Si vous préférez vous en tenir aux cartes graphiques, ce qui est parfaitement raisonnable pour la plupart des gens, notre mineur GPU ProxiChorizo est gratuit, avec son code source complet sur GitHub. Les deux mineurs parlent le même stratum ouvert : vous pouvez donc mélanger FPGA et GPU sur le même compte de pool.
Chapitre IX : Le verdict, la bouilloire sur le feu
Alors, un GPU est-il « tout simplement bien meilleur » ? La réponse honnête est celle que donne chaque ingénieur et que déteste chaque journaliste : ça dépend.
- Par puce et par watt, sur un hash de pur calcul, un design FPGA bien conçu l’emporte largement sur un GPU de la même époque, et un VU9P de dix ans bat encore une RTX 5090 flambant neuve d’environ deux contre un.
- Une vieille carte Spartan-6 perd face à un GPU moderne en efficacité, mais elle ne consomme que 25 W, ne fait aucun bruit et prenait probablement la poussière de toute façon. Pour les cartes que les gens possèdent déjà, c’est une fin heureuse.
- Sur les algorithmes memory-hard, les GPU gagnent grâce à leur bande passante mémoire, même face aux cartes FPGA équipées de HBM.
- Sur RandomX, c’est votre CPU qui gagne, ce qui était un peu le but.
- Et chaque fois qu’assez d’argent s’accumule sur un algorithme simple, un ASIC finit par débarquer, et il aura été prototypé sur un FPGA.
Les FPGA ne sont pas magiques, et ils ne sont pas l’avenir de tout le minage. Ce sont les puces que l’on sort quand un algorithme est assez simple pour être transformé en câblage, assez précieux pour mériter un bitstream, et assez jeune pour que personne n’ait encore dépensé des millions à le figer dans le silicium. Proxima, en ce moment, coche les trois cases. Et nous devons avouer un plaisir tout particulier à regarder une carte qui a miné du Bitcoin pour la dernière fois quand Gangnam Style trônait en tête des charts soumettre de nouveau des shares, tranquillement.
Un FPGA transforme un algorithme de hachage en circuit, ce qui, sur des hashs limités par le calcul comme BLAKE2b, le rend bien plus efficace qu’un GPU de la même génération : un VU9P fait environ 42 MH/J sur Proxima, contre environ 20 pour une RTX 5090. Les algorithmes memory-hard appartiennent aux GPU, et RandomX aux CPU. Notre bitstream ZTEX et notre logiciel hôte sont open source : si vous avez une carte Spartan-6 au grenier, c’est le moment idéal pour aller chercher l’échelle.