6 ms·

Recreating RP2040 PIO Interface in an FPGA

95 points by f_devd 3y ago

synergy20 3y ago
that's very cool, maybe one day it can be burnt into a CPLD or integrated into other MCUs' designs directly. Motorola used to have CPM, TI has PRU for higher end chips. All of these are doing similar things: using software to create IO peripherals on the fly.
- bri3d 3y ago
  The Pi engineers claim that at least some aspects of PIO are "patent-pending," [0] so a 1:1 reimplementation in another MCU would probably infringe on some claim or another eventually. Yes, software defined I/O is not uncommon which is one reason I'm quite curious about the specific claims in the PIO patents. Another good example is the Infineon Peripheral Control Processor (PCP) used in Tricore. It's much more powerful ISA wise than PIO, but conceptually extremely similar. 0: https://forums.raspberrypi.com/viewtopic.php?t=307115#p1837408 https://forums.raspberrypi.com/viewtopic.php?t=307115#p18374...
  - snvzz 3y ago
    Disgusting stuff. Meantime, RISC-V is trying to standardize GPIO, Watchdogs and other common peripheral interfaces.
  - deleted 3y ago
    [deleted]
  - MayeulC 3y ago
    I came here to inquire about this. The relevant patents haven't been published yet? I wouldn't include this in a commercial design due to potential infringement.
sfrigon 3y ago
That's interesting! If AMD incorporates scaled down Xilinx's FPGAs into their x86-family product line, that could bring a lot of RasperryPi's community effort into a mainstream products too (home PC) and let us experiment embedded software directly on our PC! ...and break our main PC during our experiments too, oopsie. But it would be worth it haha.
- ThrowawayTestr 3y ago
  While I love the idea of FPGA co-processors on CPUs, I'm wondering how useful they could be. I guess you could replace the video transcoding unit so you're not tied to one codec but how often do those change anyway.
  - sfrigon 3y ago
    I must admit I did not think this whole thing fully. But what was interesting to me was the fact that you could add a peripheral that was not initially intended by the manufacturers, making a mainstream motherboard more versatile. For you it may be a video transcoding unit, for someone else it may be an SPI or I2C device, PCIe, or extra ethernet, or high quality audio. I'm not sure what peripherals were implemented by the community for the RP2040 either, maybe they would not make sense on a PC.
    - bpye 3y ago
      Doesn’t PCIe already get you that today? Either with an existing PCIe -> X bridge chip, or an FPGA with PCIe capability? It’s not cheap, and you need to write device drivers etc - but that’s the case regardless.
      - sfrigon 3y ago
        Maybe PCIe already does something similar, that's not something I have knowledge about. Though there is a small difference in my opinion, where, from the point of view of the CPU, it should behave as a normal interface, thus the driver should already exist, and only require a change in the device tree (for linux). It would still require quite a bit of work: - The PIO has to behave bug-for-bug compatible with an existing driver - The exposed pins need have the proper voltage levels & electrical protection .. but that's just fantasy for now.
        naikrovek 3y ago
        sounds like PCIe, as mentioned. there are a few FPGA dev kits which are set up this way. I have one which has a dual core Atom CPU and a large FPGA connected via PCIe, and the speed is fast.
Accujack 3y ago
As soon as I read about the programmable I/O setup, it reminded me of the Propeller series chips from Parallax. The "cogs" that are the main processors of those chips aren't as general use as something like the STM32 cores, but they do certain things very, very well.
- mysterydip 3y ago
  The P2 is a huge step up from the old propeller. If you haven't checked it out, I recommend it. "smart pins" are able to do all kinds of things, almost like having mini cores along with the main cogs. I used it for a project and was able to achieve all my goals. Really happy with it.
  - yetanotherloser 3y ago
    You've got me intrigued,but also wanting more specifics. Did you share any details of this anywhere you can link to? (don't worry if not, I'm just nosy)
    - mysterydip 3y ago
      https://www.parallax.com/propeller-2/ https://www.parallax.com/propeller-2/ tons of improvements in terms of memory access etc, but pay attention to the "64 smart pins" section specifically. I use them to buffer out sub-microsecond waveforms 3ms at a time. I send it off to the smart pins then my cog is freed up for other things. I also previously used some for an HDMI GUI.
      - yetanotherloser 3y ago
        Ah, I see. Nice work. Thanks for the extra detail.
qiqitori 3y ago
The RP2040's PIO is awesome. Here are two retro-related projects I did in the last ~year. You can capture video in a weird format with PIO on one core, and output it with PIO (in a standard format like VGA, or even DVI) on the other core, like here: https://blog.qiqitori.com/2022/09/raspberry-pi-pico-15-6-khz-analog-rgb-to-vga-adapter-part-1-poc-wip/ https://blog.qiqitori.com/2022/09/raspberry-pi-pico-15-6-khz... Or you can implement old DACs that expect a weird input data format, to a certain extent, like here: https://blog.qiqitori.com/2023/03/raspberry-pi-pico-implementation-of-the-ym3012-dac-mono/ https://blog.qiqitori.com/2023/03/raspberry-pi-pico-implemen... (Now I'm almost at the end of my sabbatical but think these projects (and others) were totally worth doing even if it meant living off savings, heh.)
- polpo 3y ago
  PIO is indeed awesome! A while ago I was wondering if the RP2040 could be used as a scandoubler (and talking about it with the Chrissy who left a comment on your blog). I was originally discouraged and decided to not pursue it because the ADCs on the RP2040 are just too slow to capture video, so I'm happy to see the results of your effort!
cdcarter 3y ago
I stumbled upon this project a few weeks ago, while starting to get a better handle on how to use PIO (and the rest of the RP2040 infrastructure, like PIO/DMA interactions). I searched for it at first, thinking that an HDL implementation of PIO would be a good way to test and simulate PIO interactions and timings. It turns out there are some neat and more specific PIO simulator/emulator projects out there, so I've moved that way. Still, this project is quite interesting. I have a design I'm working on that would really benefit from 4 PIO blocks all cooperating on a piece of RP silicon. Since that's not likely to ship anytime soon, I am vaguely interested in piecing together some HDL that stitches together a RISC-V core with several PIOs.
- robomartin 3y ago
  Not sure I understand what you are saying. If you have an FPGA you can do anything you want, better and faster than the RP PIO hardware. Why replicate it? If you are talking about creating microcoded state machines in an FPGA, once again, this is the kind of thing that is almost trivial. Examples of subsystems can can be implemented this way are dynamic RAM controllers, sophisticated programmable image processors/scalers, etc.
  - cdcarter 3y ago
    I considered addressing this point in my initial post, but decided not to open the can of worms. You're right, if I have an FPGA I can do anything I want. But what I want to do is take existing RP2040 PIO programs, and write RP2040 SDK C code to run them and interact with them, but I want to drive more pins and manage more state than the RP2040 offers. If I have a design that takes two RP2040s today and some very careful communication between them, I'd love to try and run it on FPGA but not throw out all the work.
    - robomartin 3y ago
      OK, I get it. Not sure how that might work. To run compiled RP2040 SDK C PIO code on a PIO "clone" inside an FPGA you are going to have to do a ton of work. That's kind of where I was going with my question. By the time you do all that work to use an FPGA you might as well implement the functionality in hardware. I love FPGA's...and yet I hate them with a passion. When they are the right fit for the job you can't beat them. However, this comes at a pretty serious cost in terms of debug cycles per day, troubleshooting complexity and just plain time. I am known for saying that developing a solution on an FPGA takes "cubic time" when compared to other options. I have worked on a number of projects where compile times are in excess of an hour and debugging is excruciatingly painful. You need an 18 hour day just to iterate through two to four attempts at fixing a problem. Like I said, painful. These days I avoid them as much as possible or, when necessary, I prefer to license well-designed and well-tested cores that just work.

95 points by f_devd 3y ago

that's very cool, maybe one day it can be burnt into a CPLD or integrated into other MCUs' designs directly. Motorola used to have CPM, TI has PRU for higher end chips. All of these are doing similar things: using software to create IO peripherals on the fly.

bri3d 3y ago
The Pi engineers claim that at least some aspects of PIO are "patent-pending," [0] so a 1:1 reimplementation in another MCU would probably infringe on some claim or another eventually. Yes, software defined I/O is not uncommon which is one reason I'm quite curious about the specific claims in the PIO patents. Another good example is the Infineon Peripheral Control Processor (PCP) used in Tricore. It's much more powerful ISA wise than PIO, but conceptually extremely similar. 0: https://forums.raspberrypi.com/viewtopic.php?t=307115#p1837408 https://forums.raspberrypi.com/viewtopic.php?t=307115#p18374...
- snvzz 3y ago
  Disgusting stuff. Meantime, RISC-V is trying to standardize GPIO, Watchdogs and other common peripheral interfaces.
- deleted 3y ago
  [deleted]
- MayeulC 3y ago
  I came here to inquire about this. The relevant patents haven't been published yet? I wouldn't include this in a commercial design due to potential infringement.

sfrigon 3y ago

That's interesting! If AMD incorporates scaled down Xilinx's FPGAs into their x86-family product line, that could bring a lot of RasperryPi's community effort into a mainstream products too (home PC) and let us experiment embedded software directly on our PC! ...and break our main PC during our experiments too, oopsie. But it would be worth it haha.

ThrowawayTestr 3y ago
While I love the idea of FPGA co-processors on CPUs, I'm wondering how useful they could be. I guess you could replace the video transcoding unit so you're not tied to one codec but how often do those change anyway.
- sfrigon 3y ago
  I must admit I did not think this whole thing fully. But what was interesting to me was the fact that you could add a peripheral that was not initially intended by the manufacturers, making a mainstream motherboard more versatile. For you it may be a video transcoding unit, for someone else it may be an SPI or I2C device, PCIe, or extra ethernet, or high quality audio. I'm not sure what peripherals were implemented by the community for the RP2040 either, maybe they would not make sense on a PC.
  - bpye 3y ago
    Doesn’t PCIe already get you that today? Either with an existing PCIe -> X bridge chip, or an FPGA with PCIe capability? It’s not cheap, and you need to write device drivers etc - but that’s the case regardless.
    - sfrigon 3y ago
      Maybe PCIe already does something similar, that's not something I have knowledge about. Though there is a small difference in my opinion, where, from the point of view of the CPU, it should behave as a normal interface, thus the driver should already exist, and only require a change in the device tree (for linux). It would still require quite a bit of work: - The PIO has to behave bug-for-bug compatible with an existing driver - The exposed pins need have the proper voltage levels & electrical protection .. but that's just fantasy for now.
      - naikrovek 3y ago
        sounds like PCIe, as mentioned. there are a few FPGA dev kits which are set up this way. I have one which has a dual core Atom CPU and a large FPGA connected via PCIe, and the speed is fast.

Accujack 3y ago

As soon as I read about the programmable I/O setup, it reminded me of the Propeller series chips from Parallax. The "cogs" that are the main processors of those chips aren't as general use as something like the STM32 cores, but they do certain things very, very well.

mysterydip 3y ago
The P2 is a huge step up from the old propeller. If you haven't checked it out, I recommend it. "smart pins" are able to do all kinds of things, almost like having mini cores along with the main cogs. I used it for a project and was able to achieve all my goals. Really happy with it.
- yetanotherloser 3y ago
  You've got me intrigued,but also wanting more specifics. Did you share any details of this anywhere you can link to? (don't worry if not, I'm just nosy)
  - mysterydip 3y ago
    https://www.parallax.com/propeller-2/ https://www.parallax.com/propeller-2/ tons of improvements in terms of memory access etc, but pay attention to the "64 smart pins" section specifically. I use them to buffer out sub-microsecond waveforms 3ms at a time. I send it off to the smart pins then my cog is freed up for other things. I also previously used some for an HDMI GUI.
    - yetanotherloser 3y ago
      Ah, I see. Nice work. Thanks for the extra detail.

qiqitori 3y ago

The RP2040's PIO is awesome. Here are two retro-related projects I did in the last ~year. You can capture video in a weird format with PIO on one core, and output it with PIO (in a standard format like VGA, or even DVI) on the other core, like here: https://blog.qiqitori.com/2022/09/raspberry-pi-pico-15-6-khz-analog-rgb-to-vga-adapter-part-1-poc-wip/ https://blog.qiqitori.com/2022/09/raspberry-pi-pico-15-6-khz... Or you can implement old DACs that expect a weird input data format, to a certain extent, like here: https://blog.qiqitori.com/2023/03/raspberry-pi-pico-implementation-of-the-ym3012-dac-mono/ https://blog.qiqitori.com/2023/03/raspberry-pi-pico-implemen... (Now I'm almost at the end of my sabbatical but think these projects (and others) were totally worth doing even if it meant living off savings, heh.)

polpo 3y ago
PIO is indeed awesome! A while ago I was wondering if the RP2040 could be used as a scandoubler (and talking about it with the Chrissy who left a comment on your blog). I was originally discouraged and decided to not pursue it because the ADCs on the RP2040 are just too slow to capture video, so I'm happy to see the results of your effort!

cdcarter 3y ago

I stumbled upon this project a few weeks ago, while starting to get a better handle on how to use PIO (and the rest of the RP2040 infrastructure, like PIO/DMA interactions). I searched for it at first, thinking that an HDL implementation of PIO would be a good way to test and simulate PIO interactions and timings. It turns out there are some neat and more specific PIO simulator/emulator projects out there, so I've moved that way. Still, this project is quite interesting. I have a design I'm working on that would really benefit from 4 PIO blocks all cooperating on a piece of RP silicon. Since that's not likely to ship anytime soon, I am vaguely interested in piecing together some HDL that stitches together a RISC-V core with several PIOs.

robomartin 3y ago
Not sure I understand what you are saying. If you have an FPGA you can do anything you want, better and faster than the RP PIO hardware. Why replicate it? If you are talking about creating microcoded state machines in an FPGA, once again, this is the kind of thing that is almost trivial. Examples of subsystems can can be implemented this way are dynamic RAM controllers, sophisticated programmable image processors/scalers, etc.
- cdcarter 3y ago
  I considered addressing this point in my initial post, but decided not to open the can of worms. You're right, if I have an FPGA I can do anything I want. But what I want to do is take existing RP2040 PIO programs, and write RP2040 SDK C code to run them and interact with them, but I want to drive more pins and manage more state than the RP2040 offers. If I have a design that takes two RP2040s today and some very careful communication between them, I'd love to try and run it on FPGA but not throw out all the work.
  - robomartin 3y ago
    OK, I get it. Not sure how that might work. To run compiled RP2040 SDK C PIO code on a PIO "clone" inside an FPGA you are going to have to do a ton of work. That's kind of where I was going with my question. By the time you do all that work to use an FPGA you might as well implement the functionality in hardware. I love FPGA's...and yet I hate them with a passion. When they are the right fit for the job you can't beat them. However, this comes at a pretty serious cost in terms of debug cycles per day, troubleshooting complexity and just plain time. I am known for saying that developing a solution on an FPGA takes "cubic time" when compared to other options. I have worked on a number of projects where compile times are in excess of an hour and debugging is excruciatingly painful. You need an 18 hour day just to iterate through two to four attempts at fixing a problem. Like I said, painful. These days I avoid them as much as possible or, when necessary, I prefer to license well-designed and well-tested cores that just work.