- Python s’exécute directement sur un processeur personnalisé au niveau matériel, sans interpréteur ni JIT
- Le temps d’aller-retour GPIO de PyXL est de 480 ns, soit 30 fois plus rapide que le PyBoard sous MicroPython
- Il fonctionne sur un FPGA Zynq-7000, avec un CPU ARM qui gère la configuration et la mémoire
- GPIO signifie entrées/sorties à usage général ; PyXL les exécute directement dans le matériel, sans passer par une VM ni une pile logicielle
- Il offre des performances déterministes et constantes pour les systèmes de contrôle en temps réel, la robotique et les systèmes industriels embarqués
Présentation de PyXL
- PyXL est un processeur personnalisé qui exécute Python directement dans le matériel
- Il exécute du code Python dans le silicium, sans interpréteur ni JIT
- Il convertit le bytecode CPython en assembleur personnalisé, puis l’exécute sur un processeur pipeline
Caractéristiques de PyXL
- Ce n’est ni du C ni une boucle inline
- Ce n’est ni MicroPython ni un JIT
- Il n’exécute ni Linux ni de système d’exploitation
- C’est un processeur dédié à Python, conçu pour le déterminisme et la vitesse
Environnement d’exécution de PyXL
- Il fonctionne sur un FPGA Zynq-7000, avec une carte de développement Arty-Z7-20
- Le cœur PyXL fonctionne à 100 MHz
- Le CPU ARM gère la configuration et la mémoire, tandis que le code Python s’exécute directement dans le matériel
Qu’est-ce que GPIO ?
- GPIO signifie entrées/sorties à usage général et permet au logiciel de contrôler des LED, des boutons, des capteurs ou des moteurs
- Dans MicroPython, le code Python interagit avec des fonctions C qui manipulent les registres matériels
- PyXL exécute directement le bytecode Python dans le matériel, sans interpréteur ni appel de fonction, sur du matériel natif
Test GPIO
- Le test relie deux broches de la carte Arty avec un câble jumper
- Un programme Python mesure le temps écoulé entre le moment où la broche GPIO 1 est réglée à 1 et celui où un autre pin mesure 1
- Une vidéo comparant PyXL et la VM MicroPython du PyBoard permet de constater l’écart de performances
Structure des programmes PyXL
- Les programmes Python sont d’abord compilés en bytecode CPython, puis convertis en assembleur PyXL
- Un binaire est généré puis transmis à la carte Arty via le réseau
- Le CPU ARM reçoit l’application, la copie dans le matériel PyXL et la mémoire partagée, puis l’exécute
Comparaison des plateformes
- Latence aller-retour GPIO : PyXL à 480 ns, MicroPython (PyBoard) à 14 741 ns
- PyXL est 30 fois plus rapide que le PyBoard et, après normalisation par la fréquence d’horloge, 50 fois plus rapide
Avantages de PyXL
- Une VM Python repose sur un interpréteur logiciel, ce qui entraîne de l’overhead et de la complexité
- PyXL supprime ces barrières en exécutant directement le code Python dans le matériel
- L’accès GPIO est physique, le flux de contrôle est prévisible, et les performances restent constantes
Domaines d’application de PyXL
- Mise en œuvre possible en Python pur dans des systèmes de contrôle en temps réel
- Respecte des contraintes temporelles strictes pour l’inférence ML et les boucles de réponse de capteurs
- En robotique, gère le retour moteur et la fusion de capteurs avec une précision au niveau du cycle
- Convient aux systèmes industriels embarqués où le timing et la fiabilité sont critiques
6 commentaires
Comment gérez-vous les changements de version ?
Cela pourrait bien être une bonne nouvelle pour les ingénieurs HiL.
Oh, c'est fascinant.
J’ai vraiment hâte.
Le développeur de ce projet en fera une présentation à la prochaine PyCon US. Quand la proposition a été relue en début d’année, elle a déjà beaucoup fait parler d’elle parmi les reviewers, et par comparaison la présentation de la session semble presque trop modeste. Si vous allez à la PyCon, je vous recommande vivement d’aller l’écouter.
https://us.pycon.org/2025/schedule/presentation/40/
Commentaires sur Hacker News
Je me demande s’il existe des restrictions sur le type de code qui peut être exécuté, en dehors des limites mémoire ou des interactions avec l’OS. J’ai l’impression que l’idée de créer, pour un processeur sur mesure, un bytecode ciblant le runtime d’un langage dynamique n’a pas été suffisamment explorée ces dernières années. J’aimerais savoir pourquoi cette direction a été choisie, pourquoi cela semblait être une bonne idée, et comment l’implémentation a été menée
Ils ont construit un processeur matériel qui exécute directement des programmes Python, sans VM ni interpréteur traditionnels. Premiers benchmarks : un aller-retour GPIO de 480 ns, soit 30 fois plus rapide que MicroPython
Travail vraiment très cool. Je me demande si, au final, l’ensemble des fonctionnalités dépassera celui d’un langage à typage sûr avec une syntaxe Python compilé nativement, plutôt que de fabriquer du matériel sur mesure. Un garbage collector en arrière-plan n’est pas aussi simple qu’il n’y paraît, mais je dis ça à quelqu’un qui a déjà accompli un travail impressionnamment difficile
Je me demande pourquoi « compiler » Python n’est pas une pratique courante. Je comprends que l’interpréteur soit utile pour l’itération rapide, la compatibilité, etc., mais dans l’écosystème Python, pourquoi est-il admis de renoncer aux avantages de la compilation et de déverser les fichiers « source » en production ?
Très intéressant. Je me demande quelles sont les limites physiques fondamentales : précision du timing, latence et gigue. À quelle vitesse le bytecode PyXL peut-il réagir à des entrées ? Il existe quelque chose de similaire appelé ARTIQ, qui exécute du code Python avec des performances de niveau « embarqué ». ARTIQ est souvent utilisé dans des laboratoires de physique quantique. Le code Python et le FPGA doivent communiquer entre eux, ce qui est techniquement difficile et truffé d’embûches. Si PyXL simplifie cela pour l’utilisateur, c’est un gros avantage pour tout le monde
Quand C# est apparu, j’étais persuadé que quelqu’un finirait par fabriquer un processeur exécutant nativement le bytecode .Net. Je me demande quel HDL a été utilisé pour concevoir le processeur. Je me demande aussi si le langage assembleur du processeur peut être partagé. Je suis curieux de connaître les avantages qu’il y a à concevoir un processeur et un compilateur de bytecode Python, par rapport à la création d’un compilateur de bytecode pour des processeurs existants (ARM/x86/RISCV, etc.)
J’aimerais poser une question aux développeurs Python. En voyant ce projet, je le trouve impressionnant, mais en tant qu’observateur extérieur au langage, j’ai du mal à le situer. a) quelles difficultés vous avez déjà rencontrées à cause de Python, b) pourquoi Python est utile pour ce type de travail, c) ce que vous pensez de Python lui-même. J’ai eu des difficultés avec Python 2 et 3, les environnements virtuels, les bibliothèques propres à chaque version, etc. En tant que développeur PHP/Go, ça m’intéresse, mais ces problèmes me font hésiter
Travail étonnant. Chaque fois que je vois une excellente implémentation sur FPGA, je regrette que Tabula n’ait pas réussi. C’était un FPGA très innovant et très rapide
Je me demande si j’ai bien compris : un ASIC exécute un microcontrôleur dédié à Python, avec un microcode adapté à Python ? Et un compilateur transforme le bytecode Python en microcode, avec toute l’infrastructure nécessaire pour envoyer le bytecode compilé à l’ASIC ? C’est amusant. Je me demande si c’est bien ça