We’ve seen some pretty incredible hacks using the Raspberry Pi 2040. However, one of the most exciting bits of hardware onboard is the Programmable I/O (PIO). Not content with it just being a part of RP2040-based projects, [Lawrie Griffiths] has been porting the PIO to Verilog so anyone can enjoy it.
This particular implementation is based only on the spec that Raspberry Pi provides. For assembling PIO code, [Lawrie] uses Adafruit’s pioasm assembler they use for their MicroPython framework. There’s a simulator to test different programs, and the project targets the Blackice MX and the Ulx3s. A few example programs are included in the repo, such as outputting a pleasant guitar note over I2S and driving a chain of WS2812s.
The project is still incomplete but slowly making progress. It’s an incredible feat of reverse engineering. While the simulator can be used to debug programs, step through instructions, and inspect waveforms, the ultimate value of bringing the PIO to other systems is that now we can re-use the code. Things like the can2040, an implementation of the CAN bus protocol using the PIO. Or even a PIO-based USB host.
that silly assembler written in C macros from last week is coming to mind as this article asks me to contemplate how i would (will) interface with PIO now that i have a comfortable bare C environment on the rp2040
Check out https://hotwright.com/hotstate-free_v1-1 It’s an algorithm state machine that you can program in C
You should probably warn people before hot linking a zip file that doesn’t look like a zip file.
Thanks. Not done on purpose.
?
I’ve entertained the idea of doing this in VHDL before, plus adding some additional capabilities like being able to adjust the FIFO length.
I’ve been wondering if a PIO could be emulated in SW (or something similar built from scratch) on a cheap uC connected to the host with SPI/I2C, and whether anyone has already done it.
It’s a notable achievement, and will really show its worth when there’s a combination RISC-V + FPGA chip similar to the ARM-based Zynq. However if targeting an FPGA- and let’s face it, using this project to implement a PIO on an ASIC would be downright cheeky- a far better solution would be a preprocessor which translated a PIO program into Verilog in order to minimise gatecount.
If you use a ROM instead of a RAM un this verilog implementation, the synthesis tool may do the optimizations con its own. It would be a goood idea to check how much it saves
If you can glue that outputted HDL together with whatever else you’re using the FPGA for you also probably don’t need a PIO to HDL compiler. If you’re doing something complex that uses multiple PIO programs this would probably reduce gatecount.