Wsrtjtyk

SRAM based FPGAs need to load the bitstream again after power off. Meanwhile the Non-Volatile based one don't need that.

I wonder, why are more experiments and security research done on the SRAM FPGA than the the NVM based one, it seems that the volatile technology is more used regardless of its security limits (when it comes to ensuring secure boot).

(PS: I have no statistics, it is a personal observation)

The main driver is the fact that SRAM is highly compatible with the same physcal process that is used to implement the actual logic. Indeed, most FPGAs these days are based on LUTs (lookup tables), which are really just tiny bits of RAM themselves.

On the other hand, the process required to build EEPROM (nonvolatile memory) requires extra steps — to create floating gates with special oxide thickness, etc. This process is NOT directly compatible with the logic/SRAM process. This means that nonvolatile FPGAs are somewhat of a compromise in both areas.

In addition to Dave Tweed's answer regarding the fabrication processes involved, most flash-based FPGAs actually still use SRAM to drive their fabric. The bitstream is loaded into the SRAM from flash just like in a more conventional FPGA, the only difference is that the flash is internal. This architecture is evident when you look at their datasheets and appnotes. In particular, some devices like the Lattice MachXO2/3 support reprogramming their flash while the device is running, which is only possible because the device actually runs from SRAM instead of directly from the flash. So a "flash based" FPGA needs the flash in addition to the SRAM, which means it needs more die area.

Regarding security, you are right to point out that the FPGA startup process can be a weakpoint in terms of allowing the bitstream to be captured. To help close this gap, many FPGAs now incorporate support for bitstream encryption, which is based on a secure key stored in dedicated memory within the FPGA. A bitstream image is encrypted with this key, loaded into the configuration memory, and then when the FPGA starts up it reads the encrypted bitstream in, and decrypts it as it loads it into its (Some microcontrollers that require external memory have similar capabilities, and the principles are largely the same.)

More than anything, it depends on your requirements. While Size, Weight and Power (SWaP) are the main drivers for ICs in-general, if you aren't compelled to develop an ASIC because of those requirements, Performance is your next consideration, which may push you back to an ASIC anyway, but, you may be able to use an FPGA if you can afford the SWaP trade-offs.

• FLASH-based FPGAs require "no time" to configure, as they are "instant on". Your design may require this.


• FLASH technology is lower power than SRAM


• FLASH-based FPGA doesn't need a BOOT PROM, thus one chip vs. two (or more).


• You may have a requirement to power-up in the previous state.


• FLASH-based offers more Rad-Tolerant solutions. There are ways to deal with radiation requirements, or SEUs in-general, in SRAM-based FPGAs, but, Microsemi offers "hardened technology"

FLASH-based FPGAs (Actel, now Microsemi), traditionally, have not had the density or performance one could achieve with SRAM-based FPGAs, so, if performance was the driving factor, you would choose Xilinx or Altera (now Intel), or maybe Lattice.

Essentially, you are driven by the requirements of your system, and your IC specifically. Early-on you address these requirements and perform a trade study of the different FPGAs (spread sheet). SWaP and performance, followed by recurring cost are the main considerations you want to iterate on with your team (systems, CCA, maybe even SW) that is fedback to your project Chief engineer/manager. Other concerns such as reliability, manufacturability, etc. are usually provided by other team members from those respective organizations, but usually don't mean much without your initial trade, and typically won't prevent your choice.

There are articles on the web if you search "SRAM vs FLASH FPGAs", but you will likely learn more from a trade-study against your requirements using the data sheets than you will anything else.

To address the security aspect, most modern SRAM FPGAs can be configured with an encrypted stream, usually with modern encryption standards such as 256-bit AES. Arguably that's just as secure as storing the configuration internally: a dedicated attacher who is able to extract the private key from a decapped chip will also be able to read out the internal flash.

Flash-based FPGAs are typically used when the implementation is rather simple (so a large SRAM FPGA is not needed) or when an instant startup is required.