Using FPGA as a Base for Microcontrollers with User-Uploaded Cortex-M Cores

[MKNY]

The idea is to use FPGA as the foundation for microcontrollers, where users can upload a core (e.g., Cortex-M0, M3, M4, M7) and their own firmware. The goal is to provide flexibility and reduce manufacturing defects. Below is an outline of how this could work.

A manufacturer STMicroelectronics produces standardized ST_FPGA chips with a consistent design, varying only by process node (e.g., 40 or 28 or 10). Users purchase a board with this FPGA and follow these steps:

Download a bitstream for the desired core (e.g., Cortex-M4) from the manufacturer’s website. Cores can be customized, removing unneeded peripherals (timers, UART, ADC) to optimize resources and power consumption.
Upload the bitstream to the FPGA via JTAG or USB, configuring the FPGA to emulate the chosen core’s architecture (e.g., Cortex-M4).
Compile and upload their firmware for that core using a standard toolchain (e.g., STM32Cube).
If needed, users can upload a different bitstream (e.g., for Cortex-M7) and new firmware, adapting the board to a new microcontroller configuration.

Benefits

Flexibility: One chip supports various cores (from M0 for simple tasks to M7 for complex applications), suitable for a wide range of uses.
Reduced Defects: FPGA’s programmable nature allows bypassing silicon defects through configuration, potentially lowering defect rates (e.g., from 20% to 5–7%), reducing production costs.
Universality: Manufacturers can produce a few FPGA models instead of numerous distinct microcontrollers.
Monetization: The manufacturer can sell boards and core bitstreams via a website (e.g., a "Core Store" with free basic cores and paid optimized versions for specific tasks like automotive or IoT).

You always have the ability to fix architectural bugs in your newly released Cortex-Mx core without changing the silicon. This is very important.

Users download a bitstream for a core (e.g., Cortex-M4 with 2 timers and 1 UART, no FPU) from the ST website.
Use a programmer (e.g., STM32CubeProgrammer) to upload the bitstream to the FPGA.
The FPGA is configured as a microcontroller with the chosen core.
Users compile firmware in an IDE (e.g., STM32CubeIDE) and upload it to the board.

Customization: Cores can be tailored to include only necessary peripherals, minimizing FPGA resource usage and power consumption.
Core Switching: Users can upload a new bitstream (e.g., Cortex-M7) for a different task, reusing the same board.

[MKNY]

Additional the manufacturer STMicroelectronics could offer a software tool for users to customize cores before uploading them to the FPGA. This tool would allow users to:

Select a base core (e.g., Cortex-M0, M3, M4, M7).
Configure peripherals (e.g., enable/disable timers, UARTs, ADCs) to match specific project requirements.
Generate a tailored bitstream optimized for performance, resource usage, and power consumption.
Export the bitstream for upload to the FPGA via JTAG/USB.
The tool could be sold as a standalone product or offered as a subscription-based service, integrated into the "Core Store" platform.

[Danish1]

Aren’t there manufacturers who do this already? It’s a long time since I used to overhear people talking about Altera and the like.

I imagine the established vendors have quite a lead that would require significant investment for someone like ST to become competitive.

I suspect that there’s quite a lot of optimisation on a “hard-coded” arm core in fixed silicon over a customisable one on a FPGA. Maybe not peak clock frequency but certainly power-efficiency.

It feels like a very different market than the one I feel ST excels in with their stm32 offerings

[MKNY]

Here, the term 'core' refers to the microcontroller architecture described in software, which can be modified using special tools. The idea is to describe the architecture of microcontrollers in HDL and implement it on FPGA boards.

[MKNY]

You can go about this in different ways. It’s true that companies like Altera (now part of Intel) and Xilinx popularized soft cores long ago, and fixed hard-silicon ARM cores do have real advantages in peak performance and power efficiency.

That said, it’s uncommon for mainstream vendors to ship mass-market microcontrollers as FPGA-based boards today — that’s a different niche. ST, however, already has the capabilities (manufacturing scale, test/validation, and production tooling) to cut defect rates and simplify MCU production if it chose to. As I wrote earlier, implementing MCU architectures in HDL and deploying them on FPGA is a fundamentally different approach — especially valuable when you need to correct architecture bugs or iterate quickly, because you can update the design in the field instead of respinning silicon.

So we should consider all options and pick the one that fits the use case best. That’s the only practical way forward right now.

[TDK]

Who would pay $40 for an FPGA to emulate a Cortex-M4 poorly when you could just buy a Cortex-M4 for $8? I don't see the market for it.

Look at the STM32H7 with a 550 MHz core. You're not going to get that type performance running it through an FPGA fabric.

> Flexibility: One chip supports various cores (from M0 for simple tasks to M7 for complex applications), suitable for a wide range of uses.
> Reduced Defects: FPGA’s programmable nature allows bypassing silicon defects through configuration, potentially lowering defect rates (e.g., from 20% to 5–7%), reducing production costs.
> Universality: Manufacturers can produce a few FPGA models instead of numerous distinct microcontrollers.
> Monetization: The manufacturer can sell boards and core bitstreams via a website (e.g., a "Core Store" with free basic cores and paid optimized versions for specific tasks like automotive or IoT).

This feels like something written by the marketing department (with business degrees) with no input from engineering (with engineering degrees).

[MKNY]

Look, the question “who’s going to pay $40 for an FPGA instead of $8 for a ready-made Cortex-M4” makes sense, but it’s not just about the price. Like we wrote earlier — the main point is that FPGAs give you flexibility.

Yeah, a finished microcontroller is cheaper, but along with it you also get an errata — official documents listing silicon bugs and limitations that you simply can’t fix. You either work around them in software, or you live with them.

But if your core is implemented on an FPGA, then:

you can actually fix logic bugs on the fly, instead of hacking around them in code;

you can use different cores for different needs — today an M4-like one, tomorrow an M7, or even a fully custom design;

you can build an architecture without “frozen” silicon bugs, which is far more attractive for serious projects than a fixed implementation.

So this isn’t about the mass market of “cheap MCUs” — it’s about people working on critical applications, where flexibility and the ability to adapt quickly matter more than the chip’s unit cost.

This could even be a separate pilot product line. And leaders — which you still are — shouldn’t stand still.

[htxy]

In development, i would much rather have a welll documented core with flaws to work around (shoutout to the H7RS) than dealing with a FPGA. Also, unless you are a a little start-up working inside a garage in the rainforests of Congo, you should be able to spend 500$ to buy yourself all MCUs you could dream of

[TDK]

I think if you polled customers, you would find that it very much is about price.

Yes, some chips have silicon bugs. Those bugs are typically minor. It's not a major pain point. If they are major, the chip gets respun.

There are major drawbacks to using FPGAs. One of those is "compile" time which can take 30 minutes to hours. The tools are completely different. The chip behaves differently. It's not equipped to execute serial instructions quickly like an MCU is. It's a different tool entirely, not something that can be a replacement for an MCU.

And good luck implementing low-power modes on an FPGA.

[MKNY]

There’s really no such thing as a “minor” bug. Even if it doesn’t show up right away, you can still run into elusive issues with unpredictable consequences. That’s exactly the point of using an FPGA here – you can exclude blocks that are known to have bugs, or where potential issues could arise.

As for compiling a custom core – that’s a one-time thing. If someone decides to build a custom core, they only need to go through that long compile once. After that, they just use it, without having to recompile every time they change the application code.

And to be clear, I’m not suggesting replacing low-cost microcontrollers. I’m suggesting adding to the lineup. An FPGA-based option would strengthen ST’s position and give customers new possibilities with ST products. This is just an idea on the table – nothing more. The decision is, of course, always yours.