Low power FPGA

[VasinD]

Hello, folks,
I am not a guru in the programmable logic world, so I apologise if this question will look dummy for you. If you are an FPGA expert, please answer it with patience.
My initial idea was to replace an STM32L151 MCU by a soft core processor (microblaze or nios or cortex-m3) on an FPGA for an IoT project. I spent couple of days trying to find a low power FPGA or CPLD but have found nothing. So, I expected to find a modern FPGA with static power consumption similar to modern low power MCU families (like for example STM32L). I checked all  Microsemi, Lattice, Xilinx and Intel families which claim to be "low power", but all they are ridiculously power hugry in comparison with STM32L MCUs. For instance:
1. most of them have I/O leakage equal to +-10 uA against +-10 nA I/O leakage for STM32L151 (1000 times more).
2. Also, in terms of static current consumption all modern FPGAs dramatically loose the competition with STM32 (dozens of uA against 0.28 μA for STM32L151 in Standby mode).
So, my first question is: am I right in my conclusion that there is no an FPGA or CPLD on the market which might compete with STM32L in terms of power consumption?
And if your answer for my first question is yes, I would like to ask you why is it so? Is this only because of clock speed in modern low power FPGAs can go at least up to 150 MHz and higher against 30 MHz max for STM32L? Is this feasible to create an FPGA with max speed equal to 30 MHz and power consumption equal to STM32L?
I believe that FPGAs with soft cores and flexibility of their peripheral might leverage the IoT market but their power consumption has to be improved significantly. I am curious to read you opinions guys

[Yansi]

Your expectation of a low power FPGA are quite off, as you have already found out for yourself.

Leave the STM32L151 alone.

//PS: I hope the IoT trash dies out in the future. Completely and without xceptions.

[iMo]

A softcore stuff is for somebody who wants to build something "special" in his/her/it fpga, and needs the softcore for a "supporting" functionality. To build an L151 around a softcore would be a pretty laborious exercise, with a questionable result (ie. speed, power, functionality, cost, etc).

[ataradov]

Not to mention that FPGA size required to implement  Cortex-M3 (getting the licence aside) with a few peripherals will cost at least 5 times the cost of  STM32.

Replacing the MCU with FPGA is a very bad idea in general. The only time it may make sense to embed the core is when you already have the FPGA in the project for some other needs. In that case incremental price jump to absorb the MCU may be pretty low.

[colorado.rob]

FPGAs cannot match the static power consumption of a custom-built ASIC.  The reason is quite simple -- they are general purpose devices which utilize vastly more gates than which are required for any equivalent ASIC.

This is one of the reasons that APSoCs like Zynq and Cyclone V SoCs are all the rage.  The need for a CPU (MicroBlaze or Nios) is so common that it made sense to embed them into the silicon directly.  These CPU operate at a much higher frequency and over an order of magnitude better performance/power than a soft core, and consume far less silicon.

Like anything to do with engineering, there are trade-offs to be made.  In the world of FPGAs, performance and flexibility are chosen over power consumption -- especially static power consumption and leakage current.  The I/O pins, for example, are far more flexible and capable than a standard GPIO on an STM32L uC.

[ogden]

My initial idea was to replace an STM32L151 MCU by a soft core processor (microblaze or nios or cortex-m3) on an FPGA for an IoT project.

One is clear - it simply do not exist. You are asking for solution, but forgot to tell what problem you are trying to solve. - Why you want to replace STM32L151 MCU with soft core processor?

[SiliconWizard]

Indeed, the first real question to ask here would be: "what for?".

Then how exactly would you define the "IoT market"? And what exactly would require custom logic that a general-purpose MCU can't handle properly in one of those gadgets (which "IoT" devices are for the most part)?

Now if you're looking for low-power FPGAs as an addition to MCUs to perform some specific task that can't be handled by MCUs for timing reasons, you can take a look at the iCE40 series for instance, or MachXO2 ZE (there are others). But that would just be for extra functions that again can't be done properly otherwise.

All the reasons why your query is vain and why it probably doesn't make sense have been exposed in above posts.

And since you're specifically talking about IoT, one last thing to consider in favor of using an off-the-shelf MCU is that IoT devices require by definition a network connection, often WiFi, some BLE or equivalent. That requires an additional RF chip + software stack, and there are now quite a few MCUs that embed all this in just one low-power chip. You're never going to get that with a general purpose FPGA.

[VasinD]

Thank you for all your answers, guys and Happy New Year

My initial idea was to replace an STM32L151 MCU by a soft core processor (microblaze or nios or cortex-m3) on an FPGA for an IoT project.

One is clear - it simply do not exist. You are asking for solution, but forgot to tell what problem you are trying to solve. - Why you want to replace STM32L151 MCU with soft core processor?

Actually, I did not ask for a solution at all. If you read my questions carefully you will see that I asked "am I right?", "why is this so?" and "can it be improved?". Probably this was my fault, but I wanted to start this topic as a general discussion of power consumption in modern programmable logic and whether or not it might be improved with decrease of ckock speed and so on. So, this is definitely not a "suggest me a direct solution" kind of topics.

[VasinD]

Your expectation of a low power FPGA are quite off, as you have already found out for yourself.

Leave the STM32L151 alone.

//PS: I hope the IoT trash dies out in the future. Completely and without xceptions.

I consider IoT as a general concept of wireless tiny sensors for myriads of applications. For example, I have been working for a decade in the IoT for medical applications. Hope that my work and work of similar engineers in medical IoT has saved and improved thousands of lives and will save much more in the future. So, dear Yansi, I hope that IoT concept will only improve and enhance.

[ogden]

I wanted to start this topic as a general discussion of power consumption in modern programmable logic

If you want to start general discussion", then start general discussion, do not say "I have idea to replace MCU with FPGA soft core CPU for an IoT project".

[VasinD]

Indeed, the first real question to ask here would be: "what for?".

Simply because vast majority (if not all) of modern digital solutions for low power sensors have serious limitations in their architecture. Just to mention few in STM32L151 mentioned earlier:
- if your sensor has data ready pin and you have to read data after the edge change on this pin, you cannot read your data without waking up your core.
- I2C bus has ugly DMA connection only to data register, so you cannot wake up you core set 1 bit in a register and go to low power mode again. Your core has to set all this start, stop, address and so on bits and wait for completion of mentioned operations.

It does not seem like big problems, but it will be a pain in your neck if you want for example to build a batteryless device which consumes several microamps of current in average. And if I had a flexible peripheral based on FPGA fabric, I would solve this issues within hours. And think about signal processing without an intervention of the CPU. All such kind of limitations disturb me within years, that is why I am dreaming about more flexible digitall solution. Ideally, I would like to see this architecture: hard RF tranciever + hard cortex-m core + hard analog peripheral + flexible digital peripheral. But this just dreams.

[SiliconWizard]

You've still not quite answered what kind of benefits you'd see using FPGAs instead of MCUs, and that question alone would help direct the discussion IMO if you really want to discuss it / have maybe some ideas that haven't been disclosed yet.

As I said, I see one benefit: if you need custom logic in your design that can't be implemented at all, or maybe not as reliably, in pure software on a MCU. This part, only you can see what you had in mind.

But if the main reason was that you thought that could actually be a way of reducing the power consumption, as we've explained above, it just won't work, as a general-purpose reconfigurable logic IC can't beat a fully custom IC such as a MCU. It's basic physics.

Now of course, you may achieve lower power consumption with a 100% custom design adapted to a specific application. You'd need to design an ASIC to achieve this, not use an FPGA, and possibly target process nodes that are out of reach for anyone but the larger companies. And doing this would have to be seriously justified.

[SiliconWizard]

It does not seem like big problems, but it will be a pain in your neck if you want for example to build a batteryless device which consumes several microamps of current in average. And if I had a flexible peripheral based on FPGA fabric, I would solve this issues within hours. And think about signal processing without an intervention of the CPU. All such kind of limitations disturb me within years, that is why I am dreaming about more flexible digitall solution. Ideally, I would like to see this architecture: hard RF tranciever + hard cortex-m core + hard analog peripheral + flexible digital peripheral. But this just dreams.

Before looking for this, have you seriously looked at ALL the offers in terms of ULP MCUs out there? There are many these days, and certainly some that would be a much better fit than the STM32L151 you keep mentioning...

[ataradov]

Also, apart from the power consumption, you should consider memory size available for the program code and the data. FPGAs are extremely limited on memory. And usually it is the case that if you logic fits into a certain FPGA size, you will not have enough on-die RAM to store the code and act as SRM for the MCU. You will be forced to use higher density FPGA, which is more expensive. External memories are slow and hard to work with.

Standalone MCU + FPGA for custom logic is still the best solution. And depending on the application, you may be able to shift a lot of logic to the FPGA, so your MCU requirements may drop considerably. You may be able to get away with much cheaper MCU.

[ogden]

Simply because vast majority (if not all) of modern digital solutions for low power sensors have serious limitations in their architecture.

Extraordinary claims require extraordinary evidence. Try harder than mentioning just stm32 limitations. Please name list of microcontrollers you know with serious limitations, after all you say "vast majority (if not all)". I wonder - Cypress Psoc6 is in the list as well?

[VasinD]

Before looking for this, have you seriously looked at ALL the offers in terms of ULP MCUs out there? There are many these days, and certainly some that would be a much better fit than the STM32L151 you keep mentioning...

Could you please suggest me at least several options out of your "much better fit than the STM32L151" list.

[VasinD]

Simply because vast majority (if not all) of modern digital solutions for low power sensors have serious limitations in their architecture.

Extraordinary claims require extraordinary evidence. Try harder than mentioning just stm32 limitations. Please name list of microcontrollers you know with serious limitations, after all you say "vast majority (if not all)". I wonder - Cypress Psoc6 is in the list as well?

Well, within my career I used stm32, avr8, avr32, msp from Texas instruments. Also I used several RF SoC, like nRF51, nRF52, BlueNRG, CCxx family from TI. All this families have serious limitations in my opinion. Although, I did not consider Cypress, but I will, thank you for your advice.

[ogden]

Simply because vast majority (if not all) of modern digital solutions for low power sensors have serious limitations in their architecture.

Extraordinary claims require extraordinary evidence. Try harder than mentioning just stm32 limitations. Please name list of microcontrollers you know with serious limitations, after all you say "vast majority (if not all)". I wonder - Cypress Psoc6 is in the list as well?

Well, within my career I used stm32, avr8, avr32, msp from Texas instruments. Also I used several RF SoC, like nRF51, nRF52, BlueNRG, CCxx family from TI. All this families have serious limitations in my opinion. Although, I did not consider Cypress, but I will, thank you for your advice.

Besides Cypres PsoC 6 there are more MCU's with low power "peripheral accelerators". MSP have some, Silicon Labs as well. Most likely there are more. Actually I would like to address both "problems" you stated. Sensor with ready flag is nonissue unless amount of trigger events is huge. Anyway in such case solution is not to move MCU into FPGA as soft core, but design external peripheral for MCU of your choice. There are many low power programmable logic IC's around made for exactly such cases. Regarding stated I2C problem I would suggest to get rid of I2C in your low power designs first because I2C itself (it's pull-ups) is more energy inefficient than I2C-associated consumption of any low power MCU around.

[VasinD]

You've still not quite answered what kind of benefits you'd see using FPGAs instead of MCUs, and that question alone would help direct the discussion IMO if you really want to discuss it / have maybe some ideas that haven't been disclosed yet.

As I said, I see one benefit: if you need custom logic in your design that can't be implemented at all, or maybe not as reliably, in pure software on a MCU. This part, only you can see what you had in mind.

But if the main reason was that you thought that could actually be a way of reducing the power consumption, as we've explained above, it just won't work, as a general-purpose reconfigurable logic IC can't beat a fully custom IC such as a MCU. It's basic physics.

Now of course, you may achieve lower power consumption with a 100% custom design adapted to a specific application. You'd need to design an ASIC to achieve this, not use an FPGA, and possibly target process nodes that are out of reach for anyone but the larger companies. And doing this would have to be seriously justified.

Could you please explain in details this "basic physics.". This "basic physics." is not obvious for me. I googled to find a good explanation for it and did not find anything. That is why I started this thread. Please look at me first post. I asked "why is it so?". Sorry, but nobody even tried to answer this question. So, except static current and IO leakage, could anyone please explain me why, for instance, a SPI module implemented in a FPGA will consume more power than the same SPI module implemented in ASIC? Is this only because the realization inside a FPGA will consume more transistors? My assumption in the first post was that this is because a typical FPGA is made based on high-speed CMOS technology and if a manufacturer changed this technology from high-speed to low-power it might dramatically reduce power consumption.

[ogden]

My assumption in the first post was that this is because a typical FPGA is made based on high-speed CMOS technology and if a manufacturer changed this technology from high-speed to low-power it might dramatically reduce power consumption.

No matter how you try, there will be much more gates involved in soft core CPU than ASIC implementation of same CPU. After all FPGA is ASIC that emulates ASIC.

[SiliconWizard]

You've still not quite answered what kind of benefits you'd see using FPGAs instead of MCUs, and that question alone would help direct the discussion IMO if you really want to discuss it / have maybe some ideas that haven't been disclosed yet.

As I said, I see one benefit: if you need custom logic in your design that can't be implemented at all, or maybe not as reliably, in pure software on a MCU. This part, only you can see what you had in mind.

But if the main reason was that you thought that could actually be a way of reducing the power consumption, as we've explained above, it just won't work, as a general-purpose reconfigurable logic IC can't beat a fully custom IC such as a MCU. It's basic physics.

Now of course, you may achieve lower power consumption with a 100% custom design adapted to a specific application. You'd need to design an ASIC to achieve this, not use an FPGA, and possibly target process nodes that are out of reach for anyone but the larger companies. And doing this would have to be seriously justified.

Could you please explain in details this "basic physics.". This "basic physics." is not obvious for me.

An FPGA is just a bunch of logic "units" that can be configured and wired together through configuration. It's easy to understand that a directly synthesized logic function on an IC will use only the exact number of transistors required and nothing more. The same function synthesized/mapped to an FPGA will never be as efficient. It will always have to make use of the existing logic "units" (or tiles) that overall will make up for a lot more transistors than strictly needed. Also, all the unused tiles will still draw power  - static of course, but also dynamic, as clock gating in FPGAs really depends on the underlying architecture and can never be done at the transistor level! So whole block of unused transistors are still likely to get clocked. Then FPGAs also contain large clock distribution structures, that will also draw significant dynamic power even if you use very little logic tiles.

The basic physics is mostly about that: an optimized implementation (using just the needed resources) vs. an implementation on a general-purpose, reconfigurable device. It's almost impossible to make the latter as efficient.

In practice, if your needs for added custom logic are very modest, only a very small reconfigurable logic block could be enough and still be adequate power-wise. It will still not be as efficient as a custom implementation, but could still be interesting. As some have mentioned above, there are now some SoCs that contain MCU cores + FPGA. Unfortunately, they are often targeted for "performance" and general-purpose applications rather than small and low-power ones. That said, I think a few MCUs actually contain very small blocks of reconfigurable logic. I don't remember off the top of my head, but I think Microchip has a couple of them, Cypress may as well? (Others probably, I can't remember exact models though.) AFAIR, none are on really "ULP" MCUs though. The market is probably just not large enough.

Also as others have said, I'm pretty sure you can get by with embedded peripherals on a decently chosen MCU by maybe re-thinking your design and/or selecting different sensors. Not quite sure I really got the problem here. It's something about being able to access external peripherals/sensors while the MCU is in deep sleep or something? I'm not sure what the practical use case is though. It would all depend on how frequent the acccesses are I guess, and how the data is going to be used? If the MCU is not waken up, all you could do (with the right embedded SPI or I2C peripheral and DMA) is to store some values in RAM and nothing else. You'd still have to find an MCU with a DMA that can run while the whole CPU is in deep sleep. If no DMA is involved, accessing an external peripheral while in deep sleep is kinda pointless as you can't do anything with the data? Also, some ULP MCUs now provide very short wake-up time from deep sleep, so just waking up, issuing a small transfer (during which it can go back to sleep) and then do whatever with the data and get back to deep sleep is largely usable, and the average power consumption can be negligible. Unless again the access is very frequent, in which case I'm not sure what you'd do with all the data without ever waking up...

[SiliconWizard]

Simply because vast majority (if not all) of modern digital solutions for low power sensors have serious limitations in their architecture.

Extraordinary claims require extraordinary evidence. Try harder than mentioning just stm32 limitations. Please name list of microcontrollers you know with serious limitations, after all you say "vast majority (if not all)". I wonder - Cypress Psoc6 is in the list as well?

Well, within my career I used stm32, avr8, avr32, msp from Texas instruments. Also I used several RF SoC, like nRF51, nRF52, BlueNRG, CCxx family from TI. All this families have serious limitations in my opinion. Although, I did not consider Cypress, but I will, thank you for your advice.

If you're looking for very low power, AVR would certainly not be the way to go IMO. I'd like to know what kind of "serious limitations" you've found in the above, and that you're dead sure could not be worked around...

A very non-exhaustive list of parts to consider: in the STM32 family, take a look at the L4 series instead. Usually less power-hungry, and a lot more capable than the L1 series. Atmel now has some very low power MCUs in the ATSAM line (now Microchip). If you're looking for MCUs with embedded RF, apart from the CC series that you seem to know, there's now the RSL10 from On Semi, which I would recommend especially for medical devices (as On Semi is pretty good to work with for this), one of the lowest-power ARM-based MCU out there, with embedded RF on top of that. There also are the Ambiq MCUs, a bit of an outsider at the moment, but the Apollo3 blue is pretty interesting.

[laugensalm]

So, my first question is: am I right in my conclusion that there is no an FPGA or CPLD on the market which might compete with STM32L in terms of power consumption?

Well, 'it depends'. If you're just pushing data around, and put the CPU to sleep most of the time and use DMA instead, you can't beat it with an FPGA.
But there are scenarios where you can get close or even beat a CPU, once you have to do calculations of some sort.

And if your answer for my first question is yes, I would like to ask you why is it so? Is this only because of clock speed in modern low power FPGAs can go at least up to 150 MHz and higher against 30 MHz max for STM32L? Is this feasible to create an FPGA with max speed equal to 30 MHz and power consumption equal to STM32L?
I believe that FPGAs with soft cores and flexibility of their peripheral might leverage the IoT market but their power consumption has to be improved significantly. I am curious to read you opinions guys

They certainly did leverage my IoF (internet of fpga) approaches, but not so much for power saving (Ethernet Phy alone eats 50mA during bursts) as rather for safety and liability issues.
You could try to grab a soft core and run it with a few mA on a ICE40, for example the ZPU soft core architecture can be optimized for power very well. Most of the work however is figuring out sleep modes during DMA transfers, and designing this kinda logic (as SiliconWizard outlined above) is a very tedious process. Unless you have a very specific application, your development cycle might be just cheaper with a STM32.
On the other hand, you can save a lot of debugging work when you can stick just everything into the simulation.

If you want to get started with experiments, I'd recommend the ICE40. The official toolchain is not so much fun to play with, but once you're out of rookie mode, there's yosys.

[ali_asadzadeh]

Consider Chinese FPGA manufacturers, like Gowin and their GW1NRF  family, it's  FPGA + BLE  + MCU, it can be used for IOT
Also it's low power comparing to other FPGA's
https://gowinsemi.com/en/product/detail/2/

[daqq]

I asked "why is it so?". Sorry, but nobody even tried to answer this question.

Very simplified* example:
ST wants to connect two two input NAND gates together.
They use 4 transistors to make 1 NAND gate, another 4 to make another NAND gate, connects them together using one trace in the metalization/polysi layer. Done. Total transistor count: 8.

You want to connect two two input NAND gates together on an FPGA.
Let's be generous and say that to make a 6 input LUT (basic building logic block of an FPGA) you need 200 transistors. Add to that configuration circuitry for the LUT, let's be generous and say that it's just another 200 transistors. I'm guessing more. That's one NAND**, so 400.
Now, you have to connect them, using the routing infrastructure. Let's be generous and say that every interconnect is just 10 transistors, including initial configuration logic. Let's assume that you manage to have 5 connections. So 50 transistors.
Now the next NAND. +400.
Done-ish. That's 850 transistors.

By definition, an FPGA structure can't be optimized for a specific task, there needs to be an absolute truckload of redundancy, overhead etc.

* - the transistor counts for the FPGAs are extremely generous and are my guess at the absolutely lowest possible counts, likely it's much more. Guesstimate thread: https://www.eevblog.com/forum/microcontrollers/transistor-count-of-modern-fpga/
** - yes, I know that you can use a 6 input LUT as the two NANDs.