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