- Ein Custom-Prozessor, der Python direkt in Hardware ausführt und ohne Interpreter oder JIT arbeitet
- Die GPIO-Roundtrip-Zeit von PyXL beträgt 480 ns und ist damit 30-mal schneller als die des PyBoard mit MicroPython
- Läuft auf einem Zynq-7000 FPGA, wobei die ARM-CPU Konfiguration und Speicher übernimmt
- GPIO steht für General Purpose Input/Output, und PyXL führt dies direkt in Hardware aus, ohne eine VM oder einen Software-Stack zu durchlaufen
- Bietet deterministische und konsistente Leistung in Echtzeit-Steuerungssystemen, Robotik und eingebetteten industriellen Systemen
Einführung in PyXL
- PyXL ist ein Custom-Prozessor, der Python direkt in Hardware ausführt
- Führt Python-Code in Silizium aus, ohne Interpreter oder JIT
- Wandelt CPython-Bytecode in Custom-Assembly um und führt ihn auf einem Pipeline-Prozessor aus
Merkmale von PyXL
- Kein C und keine Inline-Loops
- Kein MicroPython und kein JIT
- Führt weder Linux noch ein Betriebssystem aus
- Ein dedizierter Python-Prozessor, der auf Determinismus und Geschwindigkeit ausgelegt ist
Laufzeitumgebung von PyXL
- Läuft auf einem Zynq-7000 FPGA unter Verwendung des Arty-Z7-20-Entwicklungsboards
- Der PyXL-Kern läuft mit 100 MHz
- Die ARM-CPU übernimmt Konfiguration und Speicher, während Python-Code direkt in Hardware ausgeführt wird
Was ist GPIO?
- GPIO steht für General Purpose Input/Output und ermöglicht es Software, LEDs, Taster, Sensoren und Motoren zu steuern
- In MicroPython interagiert Python-Code mit C-Funktionen, die die Hardware-Register verarbeiten
- PyXL führt Python-Bytecode direkt in Hardware aus und läuft auf nativer Hardware ohne Interpreter oder Funktionsaufrufe
GPIO-Test
- Getestet wurde, indem zwei Pins des Arty-Boards mit einem Jumper-Kabel verbunden wurden
- Ein Python-Programm misst die Zeit vom Setzen von GPIO-Pin 1 auf 1 bis zur Messung von 1 an einem anderen Pin
- Ein Video, das PyXL mit der MicroPython-VM des PyBoard vergleicht, zeigt den Leistungsunterschied
Programmstruktur von PyXL
- Das Python-Programm wird zunächst zu CPython-Bytecode kompiliert und anschließend in PyXL-Assembly umgewandelt
- Eine Binärdatei wird erzeugt und über das Netzwerk an das Arty-Board übertragen
- Die ARM-CPU empfängt die Anwendung, kopiert sie in den Shared Memory mit der PyXL-Hardware und führt sie aus
Plattformvergleich
- GPIO-Roundtrip-Latenz: PyXL 480 ns, MicroPython (PyBoard) 14.741 ns
- PyXL ist 30-mal schneller als das PyBoard und bei normalisierter Taktfrequenz 50-mal schneller
Vorteile von PyXL
- Eine Python-VM basiert auf einem Software-Interpreter, was Overhead und Komplexität verursacht
- PyXL beseitigt diese Hürden und führt Python-Code direkt in Hardware aus
- Der GPIO-Zugriff ist physisch, der Kontrollfluss ist vorhersagbar und liefert konsistente Leistung
Anwendungsbereiche von PyXL
- Kann in Echtzeit-Steuerungssystemen vollständig in reinem Python implementiert werden
- Erfüllt strenge Zeitvorgaben bei ML-Inferenz und Sensor-Reaktionsschleifen
- Verarbeitet in der Robotik Motor-Feedback und Sensorfusion mit Präzision auf Zyklusebene
- Geeignet für eingebettete industrielle Systeme, in denen Timing und Zuverlässigkeit entscheidend sind
6 Kommentare
Wie geht ihr mit Versionsänderungen um?
Das könnte für HiL-Ingenieur:innen vielleicht eine gute Nachricht sein.
Oh, wie interessant.
Darauf freue ich mich sehr.
Der Entwickler dieses Projekts hält auf der diesjährigen PyCon US einen Vortrag zu diesem Thema. Als ich den Proposal-Review Anfang des Jahres gemacht habe, war es unter den Reviewern ein ziemlich großes Gesprächsthema, aber verglichen damit ist die Vorstellungsbeschreibung des Vortrags viel zu bescheiden. Denjenigen, die zur PyCon fahren, kann ich nur empfehlen, sich das unbedingt einmal anzuhören.
https://us.pycon.org/2025/schedule/presentation/40/
Hacker-News-Kommentare
Ich frage mich, ob es Einschränkungen dafür gibt, welcher Code ausgeführt werden kann – abgesehen von Speicherbeschränkungen oder der Interaktion mit dem OS. Ich denke, die Idee, Bytecode für die Runtime einer dynamischen Sprache auf einen maßgeschneiderten Prozessor abzubilden, wurde in letzter Zeit nicht ausreichend erforscht. Ich würde gern wissen, warum diese Richtung gewählt wurde, warum sie eine gute Idee war und wie die Umsetzung ablief
Es wurde ein Hardware-Prozessor gebaut, der Python-Programme direkt ausführt – ohne traditionelle VM oder Interpreter. Erste Benchmarks: GPIO-Roundtrip-Latenz von 480 ns, also 30-mal schneller als MicroPython
Sehr coole Arbeit. Ich frage mich, ob der endgültige Funktionsumfang größer sein wird als bei der Entwicklung einer typsicheren Sprache mit Python-Syntax, die nativ kompiliert, statt maßgeschneiderte Hardware zu bauen. Hintergrund-Garbage-Collection ist nicht so einfach, wie es klingt, aber ich spreche hier mit jemandem, der bereits beeindruckend schwierige Arbeit geleistet hat
Ich frage mich, warum es nicht alltäglich ist, Python zu „kompilieren“. Ich verstehe, dass Interpreter gut für schnelle Iteration, Kompatibilität usw. sind, aber ich frage mich, warum es in der Python-Welt als akzeptierte Praxis gilt, auf die Vorteile der Kompilierung zu verzichten und „Source“-Dateien in die Produktion zu kippen
Sehr interessant. Ich frage mich, wo die grundlegenden physikalischen Grenzen liegen – also Timing-Genauigkeit, Latenz und Jitter. Wie schnell kann PyXL-Bytecode auf Eingaben reagieren? Es gibt etwas Ähnliches namens ARTIQ, das Python-Code mit „Embedded-Level“-Performance ausführt. ARTIQ wird häufig in Quantenphysik-Laboren verwendet. Python-Code und FPGA müssen dabei miteinander kommunizieren, was technisch schwierig ist und viele Fallstricke hat. Wenn PyXL das für Nutzer einfacher macht, ist das ein großer Vorteil für alle
Als C# aufkam, war ich sicher, dass jemand einen Prozessor bauen würde, der .Net-Bytecode nativ ausführt. Ich frage mich, welche HDL für das Design des Prozessors verwendet wurde. Ich frage mich, ob die Assemblersprache des Prozessors geteilt werden kann. Ich frage mich, was der Vorteil davon ist, einen Prozessor zu entwerfen und einen Python-Bytecode-Compiler zu bauen, verglichen mit einem Bytecode-Compiler für bestehende Prozessoren (ARM/x86/RISCV usw.)
Ich würde gern Python-Entwicklern eine Frage stellen. Ich finde dieses Projekt beeindruckend, aber als Außenstehender mit Blick auf die Sprache ergibt es für mich keinen Sinn. Mich interessiert: a) womit ihr wegen Python früher Schwierigkeiten hattet, b) warum Python für diese Arbeit nützlich ist und c) was ihr generell über Python denkt. Ich hatte Probleme mit Python 2 und 3, virtuellen Umgebungen, Bibliotheken für verschiedene Versionen usw. Als PHP/Go-Entwickler bin ich interessiert, zögere wegen dieser Probleme aber noch
Erstaunliche Arbeit. Jedes Mal, wenn ich eine großartige Umsetzung auf einem FPGA sehe, bedaure ich, dass Tabula keinen Erfolg hatte. Das war ein sehr innovatives und schnelles FPGA
Ich frage mich, ob ich es richtig verstehe: Läuft auf dem ASIC ein Python-spezifischer Mikrocontroller mit auf Python zugeschnittenem Mikrocode? Gibt es einen Compiler, der Python-Bytecode in Mikrocode übersetzt, sowie eine unterstützende Infrastruktur, die den kompilierten Bytecode an den ASIC übergibt? Spannend. Ich frage mich, ob ich das richtig verstanden habe