- Python se ejecuta directamente en hardware mediante un procesador personalizado, y funciona sin intérprete ni JIT
- El tiempo de ida y vuelta de GPIO en PyXL es de 480 ns, 30 veces más rápido que la PyBoard con MicroPython
- Se ejecuta en un FPGA Zynq-7000, mientras que la CPU ARM se encarga de la configuración y la memoria
- GPIO significa entrada/salida de propósito general, y PyXL lo ejecuta directamente en hardware sin pasar por una VM ni una pila de software
- Ofrece rendimiento determinista y consistente en sistemas de control en tiempo real, robótica y sistemas industriales embebidos
Introducción a PyXL
- PyXL es un procesador personalizado que ejecuta Python directamente en hardware
- Ejecuta código Python en silicio sin intérprete ni JIT
- Convierte CPython ByteCode en ensamblador personalizado para ejecutarlo en un procesador segmentado
Características de PyXL
- No es C ni bucles inline
- No es MicroPython ni JIT
- No ejecuta Linux ni un sistema operativo
- Es un procesador dedicado a Python, diseñado para ser determinista y rápido
Entorno de ejecución de PyXL
- Se ejecuta en un FPGA Zynq-7000 y utiliza la placa de desarrollo Arty-Z7-20
- El núcleo de PyXL funciona a 100 MHz
- La CPU ARM se encarga de la configuración y la memoria, mientras que el código Python se ejecuta directamente en hardware
¿Qué es GPIO?
- GPIO significa entrada/salida de propósito general y permite que el software controle LEDs, botones, sensores y motores
- En MicroPython, el código Python interactúa con funciones en C que manejan los registros de hardware
- PyXL ejecuta directamente el bytecode de Python en hardware, sin intérprete ni llamadas a funciones, sobre hardware nativo
Prueba de GPIO
- La prueba se realizó conectando dos pines de la placa Arty con un cable jumper
- Se escribió un programa en Python para medir el tiempo desde que el pin GPIO 1 se pone en 1 hasta que se detecta un 1 en el otro pin
- La diferencia de rendimiento se confirmó mediante un video que compara PyXL con la VM de MicroPython en la PyBoard
Estructura del programa en PyXL
- El programa en Python se compila a CPython Bytecode y luego se convierte a ensamblador de PyXL
- Se genera un binario que se envía a la placa Arty a través de la red
- La CPU ARM recibe la aplicación, la copia a la memoria compartida con el hardware PyXL y la ejecuta
Comparación de plataformas
- Latencia de ida y vuelta de GPIO: PyXL alcanza 480 ns, mientras que MicroPython (PyBoard) llega a 14,741 ns
- PyXL es 30 veces más rápido que la PyBoard y, al normalizar la frecuencia de reloj, resulta 50 veces más rápido
Ventajas de PyXL
- La VM de Python se basa en un intérprete de software, lo que introduce sobrecarga y complejidad
- PyXL elimina esas barreras y ejecuta el código Python directamente en hardware
- El acceso a GPIO es físico, y el flujo de control es predecible, ofreciendo un rendimiento consistente
Áreas de aplicación de PyXL
- Puede implementarse en Python puro para sistemas de control en tiempo real
- Cumple restricciones temporales estrictas en inferencia de ML y bucles de respuesta de sensores
- En robótica, maneja retroalimentación de motores y fusión de sensores con precisión a nivel de ciclo
- Es adecuado para sistemas industriales embebidos donde el timing y la confiabilidad son críticos
6 comentarios
¿Cómo manejan los cambios de versión?
Tal vez esto sea una buena noticia para los ingenieros de HiL.
Oh, qué curioso.
La verdad, me emociona muchísimo.
El desarrollador de este proyecto dará una charla sobre este tema en la próxima PyCon US. Cuando revisaron las propuestas a inicios de este año, también generó bastante conversación entre los revisores, pero en comparación la descripción de la charla es demasiado modesta. Si van a PyCon, les recomiendo mucho que no se la pierdan.
https://us.pycon.org/2025/schedule/presentation/40/
Comentarios de Hacker News
Me pregunto si hay restricciones sobre qué código puede ejecutarse, aparte de los límites de memoria o la interacción con el OS. Siento que la idea de convertir bytecode orientado al runtime de un lenguaje dinámico en un procesador personalizado no se ha explorado lo suficiente en tiempos recientes. Me gustaría saber por qué eligieron esta dirección, por qué les pareció una buena idea y cómo fue el proceso de implementación
Construyeron un procesador de hardware que ejecuta programas de Python directamente, sin una VM tradicional ni un intérprete. Benchmarks iniciales: latencia de ida y vuelta de GPIO de 480 ns, 30 veces más rápido que MicroPython
Es un trabajo muy genial. Me pregunto si el conjunto final de funcionalidades terminará siendo mayor que el de compilar nativamente un lenguaje type-safe con sintaxis de Python, en lugar de crear hardware personalizado. La recolección de basura en segundo plano no es tan sencilla como suena, pero ya estoy hablando con alguien que logró algo impresionantemente difícil
Me pregunto por qué no es algo cotidiano "compilar" Python. Entiendo que un intérprete es bueno para iteración rápida, compatibilidad, etc., pero me intriga por qué en el mundo de Python se acepta como práctica normal renunciar a las ventajas de compilar y simplemente volcar archivos de "source" a producción
Muy interesante. Me pregunto cuáles son las limitaciones físicas fundamentales. Es decir, la precisión temporal, la latencia y el jitter. Qué tan rápido puede reaccionar el bytecode de PyXL a una entrada. Hay algo similar llamado ARTIQ, que ejecuta código Python con rendimiento de nivel embebido. ARTIQ se usa mucho en laboratorios de física cuántica. El código Python y el FPGA tienen que comunicarse entre sí, y eso es técnicamente difícil y está lleno de trampas. Si PyXL logra hacerlo más simple para el usuario, eso sería una gran ventaja para todos
Cuando apareció C#, estaba seguro de que alguien haría un procesador que ejecutara bytecode de .Net de forma nativa. Me pregunto qué HDL usaron para diseñar el procesador. También me gustaría saber si pueden compartir el lenguaje ensamblador del procesador. Me pregunto cuál es la ventaja de diseñar el procesador y crear un compilador de bytecode de Python, en comparación con hacer un compilador de bytecode para un procesador existente (ARM/x86/RISCV, etc.)
Quisiera hacerles una pregunta a los desarrolladores de Python. Veo este proyecto y me parece impresionante, pero como alguien ajeno al lenguaje, no lo termino de entender. Me interesa saber a) qué dificultades tuvieron antes por culpa de Python, b) por qué Python es útil para este trabajo, y c) qué piensan de Python en sí. He tenido problemas por Python 2 y 3, los entornos virtuales, las librerías de cada versión, etc. Como desarrollador de PHP/Go me interesa, pero estas cosas me hacen dudar
Es un trabajo increíble. Cada vez que veo una gran implementación en FPGA, me da pena que Tabula no haya tenido éxito. Era un FPGA muy innovador y rápido
Me pregunto si la idea es correcta: un ASIC está ejecutando un microcontrolador dedicado a Python, con microcódigo ajustado para Python. Y además hay un compilador que convierte bytecode de Python en microcódigo, junto con la infraestructura de soporte para entregar a ese ASIC el bytecode compilado. Suena divertido. Me pregunto si lo entendí bien