FPGA ou microcontrôleur : comment trancher sur un projet embarqué
Un microcontrôleur exécute des instructions les unes après les autres. Un FPGA ne fait pas ça : il devient le circuit que vous décrivez. Toute la difficulté du choix tient dans cette phrase, parce qu'elle change ce que signifie « aller plus vite ».
Ce que fait vraiment un FPGA
Un FPGA est un maillage de blocs logiques configurables, de bascules, de blocs mémoire et, sur les familles récentes, de blocs arithmétiques câblés que l'on appelle DSP. Vous ne programmez pas un processeur : vous décrivez un circuit en VHDL ou en Verilog, un outil de synthèse le traduit en portes, puis un outil de placement-routage décide où chaque élément atterrit sur la puce et par quels chemins les signaux circulent.
La conséquence la plus importante n'est pas la vitesse d'horloge, qui est d'ailleurs modeste. Un FPGA tourne typiquement entre 100 et 400 MHz, quand un Cortex-M7 atteint 600 MHz et un Cortex-A applicatif dépasse le gigahertz. Le FPGA ne gagne jamais en fréquence.
Il gagne parce que trente traitements peuvent s'exécuter réellement en même temps, chacun dans sa portion de silicium, sans se disputer un cœur, un bus ou un contrôleur d'interruption.
Les quatre cas où le FPGA gagne vraiment
Le parallélisme large sur flux continu. Filtrer huit canaux d'un capteur à 50 Msps, appliquer une convolution sur un flux vidéo ligne par ligne, corréler en temps réel : ce sont des traitements où le même calcul se répète sur beaucoup de données. Un FPGA instancie huit filtres et les fait tourner ensemble. Un microcontrôleur, même avec DSP et SIMD, les enchaîne.
Le déterminisme à la nanoseconde. Sur un FPGA, une réponse en trois cycles d'horloge est une réponse en trois cycles, toujours, sans gigue. Aucune interruption, aucun cache, aucun arbitrage de bus ne vient perturber ce chemin. Sur un microcontrôleur, un défaut de cache ou une interruption prioritaire introduit une variabilité de quelques microsecondes. Pour un asservissement de moteur à découpage rapide, ou pour un déclenchement synchronisé sur plusieurs voies, cette différence est structurante.
Les interfaces qui n'existent pas en périphérique intégré. Un capteur d'image avec un protocole propriétaire, un bus industriel ancien, une liaison série au format inhabituel : plutôt que de faire du bit-banging logiciel coûteux, vous décrivez le protocole en logique. C'est souvent la vraie raison d'un FPGA dans un produit, bien plus que le calcul.
L'agrégation d'entrées-sorties. Cinquante lignes à échantillonner, à horodater et à agréger avant de les transmettre. Le FPGA fait le travail en amont et n'envoie au processeur que ce qui l'intéresse.
Les quatre cas où le microcontrôleur gagne
Le contrôle séquentiel. Une machine à états qui lit des capteurs, applique une logique métier et pilote des actionneurs à quelques kilohertz s'écrit en C en une fraction du temps, se débogue avec un point d'arrêt, et se modifie sans resynthèse.
Toute pile logicielle existante. TCP/IP, USB, TLS, un système de fichiers, un RTOS, une bibliothèque de traitement du signal : tout cela existe, est testé, et fonctionne. Le réimplémenter en logique n'aurait aucun sens.
Le coût unitaire. Un Cortex-M4 se trouve autour de 2 à 5 euros. Un FPGA d'entrée de gamme démarre plutôt vers 15 à 30 euros, et il lui faut souvent une mémoire de configuration externe et plusieurs rails d'alimentation séquencés. Sur un produit à 10 000 pièces par an, l'écart de nomenclature dépasse largement l'économie de temps de développement.
La consommation au repos. Un microcontrôleur descend à quelques microampères en veille profonde et se réveille en quelques microsecondes. Un FPGA à base de SRAM consomme en permanence, ne serait-ce que pour maintenir sa configuration, et se recharge à la mise sous tension. Sur un produit sur pile, c'est éliminatoire.
Le coût qu'on oublie de compter
Le vrai écart entre les deux mondes n'est pas dans le composant, il est dans le cycle de développement.
Modifier une ligne de C et reflasher un microcontrôleur prend quelques secondes. Modifier une ligne de VHDL demande une resynthèse et un placement-routage complet : de dix minutes sur un petit design à plusieurs heures sur un gros. Un design qui ne tient pas ses contraintes de temps ne produit pas une erreur claire, mais un rapport de timing qu'il faut savoir lire, et la correction relève souvent de l'architecture, pas de la syntaxe.
Le débogage change aussi de nature. Il n'y a pas de printf. Vous simulez avant, avec un banc de test qu'il faut écrire, ou vous instrumentez le circuit avec un analyseur logique interne qui consomme des ressources et impose une nouvelle synthèse à chaque changement de sonde.
C'est pour cette raison qu'un projet FPGA se juge d'abord sur la disponibilité des compétences. Une équipe qui n'a jamais écrit de VHDL ne rattrape pas ce retard en un trimestre.
Un tableau de décision
| Critère | Microcontrôleur | FPGA |
|---|---|---|
| Modèle d'exécution | séquentiel | parallèle spatial |
| Fréquence typique | 100 MHz à 1 GHz | 100 à 400 MHz |
| Gigue de latence | microsecondes | cycle d'horloge |
| Cycle de compilation | quelques secondes | minutes à heures |
| Débogage | point d'arrêt, trace | simulation, sonde interne |
| Coût unitaire | 2 à 5 euros | 15 à 30 euros et plus |
| Consommation au repos | microampères | milliampères |
Les valeurs chiffrées de cette section sont des ordres de grandeur observés, pas des spécifications. Elles dépendent du silicium, du compilateur et de la configuration. Mesurez les vôtres avant de dimensionner un produit sur ces bases.
| Piles logicielles | complètes | à décrire soi-même |
La réponse est souvent « les deux »
En pratique, les architectures qui fonctionnent séparent les rôles plutôt que de choisir un camp. Le FPGA prend l'acquisition, le prétraitement et les protocoles exigeants ; le processeur prend la logique applicative, le réseau et l'interface utilisateur.
C'est exactement ce que proposent les SoC qui associent les deux sur une même puce, comme les Zynq de chez AMD ou les STM32MP. Cette architecture évite le pire des deux mondes : décrire en logique ce qui s'écrit très bien en C, ou tenter en logiciel un traitement qui exige un vrai parallélisme.
La question utile n'est donc pas « FPGA ou microcontrôleur », mais : quelle partie de mon traitement exige un parallélisme réel ou un déterminisme au cycle près, et quelle partie sera plus simple, moins chère et plus maintenable en logiciel.
Références
- Arm, Cortex-M7 Technical Reference Manual
- AMD, Zynq 7000 SoC Technical Reference Manual
- STMicroelectronics, STM32MP1 documentation
- IEEE, 1076 VHDL, norme du langage
Pour aller plus loin
Ces arbitrages deviennent concrets une fois qu'on a écrit un premier design synthétisable, lu un rapport de timing et compris pourquoi un chemin combinatoire trop long limite toute l'horloge. C'est le contenu de nos deux formations VHDL, l'une pour les bases du langage, l'autre orientée conception pour FPGA.