Simulation FPGA pour l'électronique de puissance et les entraînements de moteurs

Principaux enseignements

• L'architecture du solveur suit le phénomène le plus rapide testé ; ainsi, une commutation du convertisseur supérieure à 100 kHz exclut un pas de temps du processeur avant même que toute autre exigence ne soit prise en compte.
• Les solveurs CPU ont un temps de calcul compris entre 10 et 50 microsecondes, tandis que les solveurs FPGA atteignent 200 à 500 nanosecondes ; cet écart détermine quels effets de commutation apparaissent.
• La résolution FPGA limite la flexibilité en raison d'une plage de virgule fixe, d'une taille de modèle plafonnée et de longs flux de bits, ce qui fait du partitionnement précoce entre le CPU et le FPGA la décision la plus importante.

La simulation FPGA permet de boucler une boucle de contrôle plus rapidement que n'importe quel processeur ne peut effectuer un seul pas de temps.

Les convertisseurs de puissance repoussent sans cesse les limites de leurs fréquences de commutation, tandis que les modèles utilisés pour les valider affichent une résolution à la microseconde. Les systèmes de moteurs électriques représentent déjà 53 % de la consommation mondiale d'électricité , et la quasi-totalité d'entre eux sont désormais connectés à un convertisseur à découpage dont la reproduction sur banc d'essai doit être fidèle. C'est précisément l'écart entre les résultats simulés par un solveur CPU et le comportement réel du matériel qui pose problème lors de la validation.

La question de l'architecture ne porte pas sur la vitesse brute. Il s'agit de résoudre les événements de commutation à l'échelle de temps à laquelle votre contrôleur les perçoit. Un solveur CPU à 25 microsecondes et un solveur FPGA à 250 nanosecondes ne produisent pas de résultats légèrement différents sur un convertisseur de 100 kHz. L'un renvoie une forme d'onde exploitable, tandis que l'autre renvoie une moyenne qui masque le comportement que vous testez.

Que signifie la simulation FPGA pour un modèle en temps réel ?

La simulation FPGA déplace le solveur du logiciel séquentiel vers les portes logiques. Les équations du circuit deviennent un pipeline arithmétique fixe, intégré à la structure du FPGA, et ce pipeline génère une nouvelle solution à chaque cycle d'horloge. Les pas de temps se situent entre 200 et 500 nanosecondes pour les modèles de convertisseurs, les temps de parcours des entrées et sorties étant mesurés en dizaines de nanosecondes.

Un onduleur triphasé à deux niveaux illustre clairement cette différence. Six interrupteurs, leurs diodes antiparallèles et les équations nodales associées sont compilés en blocs arithmétiques à virgule fixe, tous évalués en parallèle. Le solveur ne récupère jamais d'instruction, n'attend jamais sur une ligne de cache et ne cède jamais la main à l'ordonnanceur du système d'exploitation. Le résultat est une latence constante à chaque étape, caractéristique essentielle lorsqu'un contrôleur physique boucle la boucle de courant en fonction du modèle.

Ce déterminisme a une conséquence sur la conception. La taille du modèle est fixée lors de la génération du flux binaire ; les ressources du dispositif limitent donc le nombre de commutateurs, de nœuds et de modèles de machines pouvant être gérés simultanément. Les ingénieurs qui considèrent le FPGA comme un accélérateur extensible en cours de projet s’en rendent compte tardivement.

Pourquoi les intervalles de temps calculés par le processeur s'arrêtent-ils aux alentours de 10 microsecondes ?

Un cœur de processeur évalue un modèle opération après opération ; le pas de temps doit donc couvrir la résolution complète de la matrice, la gestion des interruptions et les transferts d'entrée/sortie. Les modèles de réseaux électriques en temps réel atteignent leur limite entre 10 et 50 microsecondes sur un cœur dédié. En dessous de ce seuil, il n'y a plus de marge de manœuvre pour les dépassements.

La limite n'apparaît que lorsque la fréquence de commutation augmente. Un réseau de distribution de 60 Hz, résolu en 50 microsecondes, génère plus de 300 échantillons par cycle fondamental, ce qui est largement suffisant. Si l'on applique le même solveur à un onduleur de 20 kHz, chaque période de commutation ne reçoit qu'un seul échantillon ; le rapport cyclique appliqué par le modèle est alors quantifié par le pas de temps et le courant d'ondulation qu'il indique est fictif. L'acquisition et l'interpolation des signaux de porte horodatés permettent de récupérer une partie de cette précision, ce qui est souvent suffisant pour une commande à 5 kHz. Cependant, cette technique ne peut pas compenser un temps mort de 500 nanosecondes ni une désaturation transitoire se produisant entièrement entre deux échantillons.

« Si l’on applique le même solveur à un onduleur de 20 kHz, chaque période de commutation reçoit un échantillon ; le rapport cyclique appliqué par le modèle est donc quantifié par rapport au pas de temps et le courant d’ondulation qu’il indique est fictif. »

Comparaison de la précision de commutation des solveurs CPU et FPGA

La principale différence entre les solveurs CPU et FPGA réside dans l'emplacement des calculs. Un CPU exécute le modèle sous forme d'instructions séquentielles, tandis qu'un FPGA dispose les mêmes équations spatialement et les résout en parallèle à chaque cycle d'horloge. Cette différence structurelle explique la différence entre un pas de temps de 25 microsecondes et un pas de 250 nanosecondes.

Aucune des deux architectures ne s'impose définitivement. Un réseau de distribution de 400 nœuds avec logique de protection fonctionne aisément sur les cœurs d'un processeur et occuperait un FPGA entier avant même que la moitié ne soit modélisée. Un convertisseur en carbure de silicium de 150 kHz, avec des pertes de commutation au niveau du composant, ne peut fonctionner sur un processeur avec une fidélité acceptable.

Le temps de compilation est l'élément que les équipes sous-estiment le plus. L'édition d'un modèle CPU est prête en quelques secondes, tandis que la génération d'un flux binaire FPGA prend des dizaines de minutes, ce qui influence la planification d'une session plus que la vitesse d'exécution du modèle.

Quel est le pas de temps requis par votre fréquence de commutation ?

Choisissez le pas de temps en fonction de la période de commutation plutôt que du matériel déjà installé. Pour obtenir des valeurs précises d'ondulation et de pertes, il faut environ 50 à 100 échantillons par période de commutation ; la fréquence de commutation du convertisseur sert donc de valeur de référence avant tout autre calcul.

Le calcul permet de concrétiser les limites.

• Un variateur IGBT de 10 kHz a une période de commutation de 100 microsecondes, donc un pas de temps de 1 microseconde maintient l'erreur de rapport cyclique proche de 1 %.
• Un étage en carbure de silicium ou en nitrure de gallium de 100 kHz a une période de 10 microsecondes, ce qui repousse le pas de temps à environ 100 nanosecondes.
• Un temps mort de 500 nanosecondes disparaît complètement à tout pas de temps supérieur à une demi-microseconde.
• L'amplitude du courant d'ondulation est faible lorsque moins de 20 échantillons sont inclus dans chaque période de commutation.
• La résolution de capture des portes définit le seuil pratique, car une commande de service que le simulateur ne peut pas horodater ne peut pas être reproduite.

Ces chiffres expliquent pourquoi tant de bancs d'essai finissent par être mixtes. Les réseaux thermiques et les charges mécaniques évoluent en quelques millisecondes et gaspillent les ressources du FPGA, tandis que la commutation des convertisseurs s'effectue en quelques nanosecondes et renvoie des valeurs inexploitables sur le processeur.

Tests de commande de moteur pris en charge uniquement par la résolution FPGA

Les modèles de commande de moteur sollicitent davantage les solveurs FPGA que les convertisseurs seuls, car la machine et l'onduleur doivent effectuer la résolution à la même fréquence. La saturation, les harmoniques spatiales et la position du rotor évoluent toutes au cours d'une seule période de commutation sur une machine à aimant permanent à grande vitesse ; leur moyennage élimine donc les effets que vous testez.

Un moteur de traction tournant à 18 000 tr/min avec 4 paires de pôles produit un courant fondamental de 1 200 Hz sous une porteuse d'onduleur de 20 kHz. L'ondulation du couple dans cette configuration provient du flux magnétique, qui varie en fonction du courant et de l'angle du rotor. C'est pourquoi les modèles de machines sur FPGA utilisent des tables de consultation issues de la méthode des éléments finis plutôt que des valeurs d'inductance constantes. Les ventes de voitures électriques ont dépassé les 20 millions d'unités en 2025 , et la charge de travail liée à la validation de ces groupes motopropulseurs a incité à intégrer la modélisation des machines dans la matrice FPGA.

Les tests de défauts complexifient encore la situation. Un court-circuit entre spires dans un enroulement statorique se développe sur quelques degrés électriques, et une désaturation de l'onduleur se résorbe en moins d'une microseconde. L'exécution de la bibliothèque machine et du modèle de commutation sur le même dispositif, comme le fait OPAL-RT sur ses simulateurs de classe OP5707XG, permet de les intégrer dans une seule résolution déterministe, de sorte que le contrôleur testé détecte le défaut au moment précis où il se produit au niveau matériel.

Les modèles FPGA vous coûtent en flexibilité et en temps de compilation

Les solveurs FPGA privilégient la résolution à la facilité d'utilisation. Les modèles fonctionnent en arithmétique à virgule fixe avec une plage numérique définie lors de la compilation, le nombre de commutateurs et de nœuds est limité par les ressources du dispositif, et chaque modification structurelle nécessite une reconstruction complète du flux binaire, ce qui prend des dizaines de minutes au lieu de quelques secondes.

La plage numérique est source de nombreuses surprises. Un solveur à virgule fixe configuré pour un bus CC de 800 V et des courants de phase de 400 A saturera ou perdra en précision si le même modèle est réutilisé pour un onduleur de chaîne de 1 500 V sans rééchelonnement. La visibilité du débogage a également un coût, car l'analyse d'un signal au sein du circuit nécessite son acheminement vers une sortie de surveillance et sa reconstruction. Aucune de ces contraintes ne remet en cause l'utilisation de solveurs FPGA. Toutes deux plaident en faveur d'une identification précoce des parties du modèle nécessitant une résolution nanoseconde.

Adapter l'architecture du solveur aux tests pertinents

L'architecture appropriée est celle qui détermine le phénomène le plus rapide que vous souhaitez observer. Si votre contrôleur réagit à des événements inférieurs à la microseconde, seul un solveur FPGA permettra de les reproduire fidèlement. En revanche, si l'élément le plus rapide du modèle est un transitoire mécanique de l'ordre de la milliseconde, l'utilisation des ressources FPGA sera inutile.

La plupart des bancs d'essai ayant une durée de vie de plusieurs années ont été délibérément partitionnés. La grille, la charge mécanique et la logique de supervision sont exécutées sur les cœurs du processeur avec une latence de 25 à 50 microsecondes, le convertisseur et la machine sur le FPGA avec une latence de quelques centaines de nanosecondes, et l'interface entre ces éléments est suffisamment bien documentée pour permettre des extensions ultérieures.

La rigueur lors du premier appel de partitionnement porte ses fruits au fil du temps. Choisir l'architecture du solveur en fonction des lois de la physique plutôt que d'un catalogue de matériel permet de préserver l'utilité d'un banc d'essai à mesure que les convertisseurs testés gagnent en vitesse. C'est le raisonnement appliqué par OPAL-RT lorsque les ingénieurs demandent quelles parties d'un modèle de variateur doivent être intégrées au modèle. Définir correctement les limites dès le départ vous permettra de consacrer votre temps à tester le contrôleur plutôt qu'à discuter avec le simulateur.

« L’architecture adéquate suit le phénomène le plus rapide que l’on souhaite observer. »