[syntheticgate]

Not really, at least not apples-apples for something like a Pi.

There are a couple of different aspects to this, one is that soft-logic it typically slower than hard-logic so you just can't get comparable frequencies out of a soft implementation. For datapath designs, this is typically solved by going wider, but that isn't quite as helpful or practical for all aspects of a processor implemented in soft logic.

If you look at the specs for this softcore processor, they have much less performance than a Pi, even when you're using some of the biggest and more $$ families of FPGAs: https://www.xilinx.com/products/design-tools/microblaze.html....

I'd say that is on-par with similar complexity soft-core CPUs from other vendors or even open-source ones.

With respect to the design transparency, it kind of depends on how much you care about the black-box compilers required to use a lot of these advanced chips. You can feed open-source RTL into them, but there's still a proprietary black-box compiler/fitter/place-route etc for a lot of these.

There's some work toward open toolchains from yosys and https://f4pga.org/, but none of the big FPGA companies seem very bought-in or willing to help in big ways, so it's been a community best-effort, and for some of the fancier devices, you still have to use the proprietary tools to build bitstreams.

[nonrandomstring]

Interesting that as well as speed, there's more to "transparency" than meets the eye. Thanks very much to you and the other commenters. So most of the FPGA tools are proprietary, as they were when I looked at them 10 years ago? Wonder why there is little FOSS movement.

I see there is a gap, between fun hobby projects like building a CPU from discrete gates on 10 breadboards, and an actual viable (but slow), microprocessor (and SBC) that can be totally audited and provably secure (at least to a good logician).

[mips_r4300i]

Doing synthesis is easy. Making a fitter is a lot harder, but can be done. But making a really optimized fitter that handles all sorts of fabric-specific oddities, hits the highest Fmax, and critically, can be timing verified to guarantee timing closure at the target operating temp, that is very, very difficult.

Where the only real open toolchain (Yosys) fails hard is in hard IP blocks, and timing analysis. These are two critical parts of using modern FPGAs, and they require far more information than is ever documented anywhere. Without timing analysis you can't do timing driven synthesis, which is sort of like closing the control loop for optimizing the design.

Device support in Quartus for a simple FPGA family like the Cyclone 3/4/10LP (they are just die shrinks) takes several hundred megs. Most of that is in the timing model dbs. The rest lies in the hard IP models.

So, not that Yosys et al is not great work (outstanding really), but they can only really practically target the easiest low hanging fruit as it relates to FPGA compilation.

Finally, nobody uses softcore CPUs for any substantial processing. They are inefficient and waste precious fabric space. As an example, using up routing wiring for a softcore can negatively impact your Fmax on the rest of the design. As a rough guide, a cheap low end FPGA could run some simple arch like MIPS at maybe 150mhz with a tailwind, but that would quickly decrease if you were to do anything else useful with the FPGA. Higher end chips like the Intel 10 series could maybe hit 400 mhz or a bit more, so really not super impressive compared to dedicated silicon.

The one place you will typically see softcores are

1. System bring up in very large designs

2. Babysitting more complex IP blocks (DDRx ram controller calibration and register programming), HDMI/Display port IP clocking calculations and supervisions etc

3. Toy/research applications

It is virtually always cheaper and more practical to throw on a STM32 or any microcontroller that talks to the FPGA, and it is very rare to not have both in a system.

[RetroTechie]

4) Custom accelerators.

For some HPC applications one can use high-performance cpu that includes wide vector units or other application-optimized cpu features. Or (for example) wire an FPGA to a CPU (for control / configuration) & network, and do the heavy lifting in the FPGA. Iirc there's even a few cpu's with embedded FPGA fabric inside.

As for OP's question: there also exist FPGAs with hard cpu cores included. But this would essentially replace [closed firmware blobs] with [proprietary FPGA design software]. Not to mention the job of implementing all required peripherals in the FPGA. Probably not a good deal...

If security / transparency is #1 concern, I'd go hunting for some hardware where open/source firmware is available for included peripherals. Maybe you won't find something 100% open that suits your needs. But with some research, probably close. And maybe you get lucky.