Lots of microcontrollers will accept Python these days, with CircuitPython and MicroPython becoming ever more popular in recent years. However, there’s now a new player in town. Enter PyXL, a project to run Python directly in hardware for maximum speed.
What’s the deal with PyXL? “It’s actual Python executed in silicon,” notes the project site. “A custom toolchain compiles a .py file into CPython ByteCode, translates it to a custom assembly, and produces a binary that runs on a pipelined processor built from scratch.” Currently, there isn’t a hard silicon version of PyXL — no surprise given what it costs to make a chip from scratch. For now, it exists as logic running on a Zynq-7000 FPGA on a Arty-Z7-20 devboard. There’s an ARM CPU helping out with setup and memory tasks for now, but the Python code is executed entirely in dedicated hardware.
The headline feature of PyXL is speed. A comparison video demonstrates this with a measurement of GPIO latency. In this test, the PyXL runs at 100 MHz, achieving a round-trip latency of 480 nanoseconds. This is compared to MicroPython running on a PyBoard at 168 MHz, which achieves a much slower 15,000 nanoseconds by comparison. The project site claims PyXL can be 30x faster than MicroPython based on this result, or 50x faster when normalized for the clock speed differences.
Python has never been the most real-time of languages, but efforts like this attempt to push it this way. The aim is that it may finally be possible to write performance-critical code in Python from the outset. We’ve taken a look at Python in the embedded world before, too, albeit in very different contexts.
Wow all that work and still several times slower than C
It’s a start. And a good one.
It’s about as fast as PIC16F1517. All that effort could’ve been spent far more productively, for example watching Czech Casting.
Why I gave up jogging, all that sweat and still can’t beat Usain Bolt in a race 😤
It’s not executing or running any Python. This is someone’s clever custom ISA and there is no python bytecode anymore once the actual program executes. The source language just happens to be python, by the end it is something entirely else for the custom processor which just looks like an FPGA that is fed data by an ARM device.
Whilst this is smart and intelligent, the promise what it does is misleading a little, probably not intentional. Given the cruft of several chips optimizing something into something entirely new, the speed gains seem rather unsurprising. I am sure some assembly genius can just take an MCU at a certain MHz speed and even laugh about my C code.
Yeah exactly my thoughts. This can be achieved by writing a compiler which would turn python in instructions for whatever architecture it must run on. Its the same as writing C or C++. It still compiles to instructions in the end
Going by the title of the post I assumed they had built a custom processor which executed Python in hardware, like ARM Jazelle or those old Forth chips. Although again, that’s not too different from writing C but they did have special hardware which actually ran java bytecode in hardware, so its different too
We’ll have to see what makes the hardware part so special in this. I don’t really care about a “Python processor” much like we also don’t have a “C++ processor” or “Java processor”. The latter has been tried and failed.
But I would give this a fair chance versus the Java attempt, because the way Java/C#/etc. runs on modern systems makes more sense (e.g. JIT compilers which can always optimize for the host ISA). Doing the Python > bytecode > C > machinecode step statically makes sense, but I do wonder what magic sauce is in that bytecode > C > machinecode part, and perhaps more importantly, how fast that would have executed on that 168MHz ARM chip instead. I bet its not going to be 14.7us.
Java processors aren’t considered a failure, at least not by the numbers. They are embedded in the chips found in essentially every payment card issued in the last decade, with billions of them deployed around the globe.
I think I checked the board and it was 250 USD in the OP. So if that won’t execute code fast after optimizing it multiple times, I’d be feeling tricked ;)
I fully see the hacker who did this is clearly intelligent, but it’s not really a cheap way.
Yeah, that’s what I was thinking.
Why not execute the bytecode directly?
That would have been closer than this.
But that’s still a lot of work, just not what I expected reading the headlines.
If you are going to compile it you might as well use C/C++.
Still a cool concept. I can’t wait for the source code to be released.
Python is also compiled — typically to CPython bytecode.
PyXL takes that bytecode and translates it into a custom instruction set that’s executed in hardware.
So while there’s a compilation step, it doesn’t turn Python into a static language like C — PyXL preserves dynamic typing and stack semantics, but runs them far more efficiently.
I write C and C++, but if I could write python and compile it would be much faster to write initially.
Thats part of the reason I’m using tinygo for a current project. Compiled, a GC, and a decent amount of python like syntax
Nice work, I would love to have spare braincells (and time) to get into FPGA. Seems like a fun project. ARM did once have instructions to accelerate the JVM. One thought, would not a compiler for python do a better job? I don’t do python so no idea how good the compliers for it are. I can’t see why a good compiler could not make it run as good as C code????
A classic example of trying to use the wrong tool for the job. Perhaps the likes of CircuitPython and MicroPython are fine for simple projects where performance is not a concern and provides an easy path into microcontrollers for people who already know some python. There come a point however where you have to learn something new to achieve your goals.
Python seems to be following a similar path to BASIC, it was the language of choice for beginners to learn programming and some very good software was developed using it, then we had things like the BASIC Stamp that enabled people to use BASIC on a microcontroller, but eventually, if you wanted to progress to building more complex projects, you had to move on from BASIC.
I have no problem with Python, it is a perfectly good language that I use myself for many things, but it just isn’t a good fit for microcontrollers, learn something new instead of trying to force your preferred language to do things it isn’t intended for.
I beg to differ. Having micropython on a microcontroller presents some advantages:
– when developing you can use pye (python editor) on the controller itself and edit files directly. No compiler and flashing needed. When the code is working and ready, it can be incorporated into micropython source, then available after flashing
– performance-critical parts can be rewritten in C and wrapped with Python. then you have the best of both worlds
For rapid prototyping, it´s a damn efficient workflow.
I have to beg to differ. Not just a learning language or ‘have to move on’. It is a perfectly good language for some microcontrollers (like RP2040 and RP2350) for most things. I’ve yet had to drop down to C (and I know this language very well) to improve performance for something I am doing. There is a point where performance is ‘good enough’ now. To read a temperature, to trip a relay, to read open/close status, etc. We are not back in the day where you had to get the last bit of speed and memory use out of the code. With PIO and multi-core you even have more options. Obviously don’t use Python where it won’t fit (use C/Assemby or other favorite compiled language), but don’t be afraid to use Python more and more as the new controllers get more powerful. It is a win for ease of use. That’s of course in my humble opinion.
“We are not back in the day where you had to get the last bit of speed and memory use out of the code. ”
Micro$oft effect: If it’s bloated and runs poor, you(user) need MORE POWER(to make up for our poor coding)
I am old enuff to remember what could be done(very well) on a C64 or 8086.
Quantity not quality is now the rule.
“Quantity not quality is now the rule.”
Just like what has happened to Amateur(ham) Radio over the last 20++ years.
-and-
Many Linux distros are also moving that way :(
(looking at you Ubuntu)
You haven’t really contested the idea that “CircuitPython and MicroPython are fine for simple projects where performance is not a concern and provides an easy path into microcontrollers”
The examples of tasks you’ve given are trivial, they do not use a fraction of a percent of the capability of a modern MCU, and are tasks that would otherwise be accomplished via simple analog components or ICs.
Keep in mind a 20 year old ATmega2560 with 256kb of program memory and 8kb of RAM can run an 8 cylinder gasoline engine with sequential fuel and spark. The fact that you can write a basic IO program using a Python toolchain is inconsequential, you’re hardly utilizing the MCU to any real extent.
I agree completely. Python was for me a means to doing some work that required less mental investment than a compiled language. I assumed that C/C++ would take too long to grasp and be unwieldy. In the end I found that C was suitable for math/algorithmic work, but not a good choice for file input/output and raw data encoding from scratch (for png or wav for example). Python has perfect modules with easy and clean function calls. The math is far too slow in Python. I need to do computations that are time consuming. And C is the only feasible one unless Im willing to wait days/weeks to run in Python vs hours/days in C.
I develop FPGA modules and write embedded code for a living. At 100MHz the Zynq-7000 can toggle/read IO in ~150-200ns through the general purpose AXI interface between the PS-PL using canned peripherals from Xilinx, and 100-150 is using custom perioherals. It can be done in under 100ns if you stay in the PS only and use MIO GPIO. And the C code for that specific task is about the same number of lines as the python example.
Don’t get me wrong, I use Python almost daily for testing and data analytics and it’s great for quickly whipping something up; but if performance really matters to you then just learn C for your embedded system.
The missing information is, MicroPython can run 50 times faster than MicroPython with a couple built-in decorators and some style rules. From a demonstration by Damien George in 2018, I recently ran the examples on some new ESP32 boards and got the same results as the 2018 tests on STM32F407.
It simply involves using local variables and functions and/or the @micropython.native decorator.
2018 demonstration here. https://www.youtube.com/watch?v=hHec4qL00x0