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.

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.

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.

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.

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.

> I'm not sure what peripherals were implemented by the community for the RP2040 either, maybe they would not make sense on a PC.

Well, someone implemented bit-banging Ethernet TX: https://news.ycombinator.com/item?id=35810281

Check out the Xilinx "Zynq" series of FPGAs. They have a lot of uses.

In that case the CPU is basically the co-processor for the FPGA. I've yet to see a use that wasn't primarily using the FPGA because it needed to be an FPGA, they're not great if you just want to run something fast (outside of a few small uses).

You can already experiment with fpgas on a pc. Get Vivado, and then you can code and simulate logic.

Always keep in mind that one of the harshest limits on PC design is the number of pins on the CPU.

I really doubt we will see GPIO pins available directly from the CPU, and if they don't come directly from there, there isn't much difference from using a PCIe or USB adapter.

Or, in other words, what you want can already be done about as well as it will ever get. The hype for adding FPGAs into PCs is for using them as co-processors, completely inaccessible for any other hardware.

AM4 has 12 dedicated GPIO pins and ~30 pins where GPIO is shared with other functions. On the other hand these are mostly meant for platform control, and maybe blinking LEDs, not for user-space bitbanging something there.

Also of note is that both Ryzen IODs and Intel PCHs contain what could be called "half of an ESP32" connected to few IO pins under the name of on-board HD audio.

What you're asking for now exists, Zen 4 mobile SKUs allegedly ship a Xilinx design on the die for "AI Acceleration" (some of their Versal fabric over some weird bus), that has absolutely 0 external software consumers beyond some vaporware about video effect software for Windows 11 e.g. background image removal and background noise removal. They really just aren't very easy to program or use externally, and require lots of integration work, and that remains a major limiting factor in practice. The pure silicon-area overhead is also pretty severe compared to a fixed ASIC (think ~50-100x worse), limiting their practical size.

There are other considerations; large FPGAs are kind of slow to program and have limited or fixed support for multi-tenancy, for example, you have to carve up the device into fixed units ahead of time and divvy those out, and unused resources cannot be re-used. It seems like "time-multiplexed" FPGAs, such as what Tabula was trying to accomplish before going bankrupt, might be better suited for that, which has other tradeoffs. I do wish you could get something high-speed, attached to a desktop class processor.

Fun peripherals aren't really the reason for the RPi's large community, anyway. That result is mostly a mix of software support, pricing, and being in the right place at the right time.

"compared to a fixed ASIC" seems like a bit of a harsh comparison.

The ideal fixed ASIC is as die-facilities-efficient a solution to a particular problem as you're going to get. The ideal FPGA is as generalised a solution to a large bucket of problems as you can get. Do they have to compete?

Ease of programmability though, there I agree and more. A chip facility can't be exciting or even interesting if it's hidden behind being a giant pain in the backside to drive.

(disclaimer: I used to be really interested in this stuff, but the problems I was interested in were eaten up by general processors and simple uses of GPUs and I'm just not interesting enough to have problems that really justify exciting hardware any more... more power to you if you still do)

Coarse Grained Reconfigurable Arrays (CGRAs) are the only way I see accelerators taking off. They reconfigure a lot faster and I believe they have better area utilization at the expense of bit-level programmability. I don't see many use cases for the FPGAs bit-level reconfiguration in an accelerator anyway so I doubt it would be missed.

> Fun peripherals aren't really the reason for the RPi's large community

What many might not realize is that the RP2040 got a massive boost due to supply chain issues affecting the STM32 line. We had to choice but to redesign a board to adopt the RP2040 when STM32's were being quoted at 50+ week lead times. It was a black swan event like no other.

We would have never touched the RP2040 without such an overwhelming forcing function in place. The chip has serious shortcomings (example: no security) and the company could not give one shit about the needs of professional product developers. Just asking for proper support under Windows was a nightmare.

Not sure if things have changed, at the time they seem to have no understanding of how real products are developed, tested, qualified, certified, evolved and supported over time.

It's one thing to make little boards for educational markets. It's quite another to build embedded systems that are part of complex multidisciplinary products non-trivial service lifetime and support.

We dropped the RP2040 like a hot potato as soon as STM32's became available.

Making the decision to redesign the boards was a no-brainer. On the one side you are dealing with a company that makes educational boards that have the luxury of appealing to an audience that shrugs off such things as reliability, tools and manufacturing process integration. On the other side (STM), you have the support of an organization and an ecosystem that has been dedicated to meeting the needs of professional product developers for decades. The difference, from my side of the fence, is impossible to miss. Black swan events sometimes make you do things you will live to regret. For me, this was one of them.

BTW, I do like aspects of this chip. Someone should take it and run with it in a professional manner. Raspberry Pi Ltd. isn't that company. It wasn't until an engineer from India did the hard work to attempt to create a better experience under Windows that the company "released" a solution. This "solution" resorts to such things as reinstalling VSCode. Brilliant.

Do you have a view on the TI 'PRU' devices as found in the BeagleBoard chips? I believe they are similar in functionality.

I know what TI's PRU does, however, I haven't used them at all, I can't really offer a valid opinion.