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.
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.