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.
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.
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.
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.
One thing that's nice is that if you have this, you can use an FPGA as a devkit, figure out all the bits and pieces that you need, then use the RP2040 in a "final" product.
FPGAs are obviously cool and powerful, but there's a pretty big cost differential.
On top of that, an FPGA is not a replacement for a CPU in itself. Soft cores are costly in gates. Of course "FPGA + CPU" is a thing, but in that case... if you can get away with a CPU by itself your tooling gets a lot simpler.
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.