21
\$\begingroup\$

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)

\$\endgroup\$
  • \$\begingroup\$ I am not sure about your statistics, but FLASH FPGAs are relatively new comparing to to SRAM ones. So that could be a reason if your data is true. \$\endgroup\$ – Eugene Sh. Nov 5 '18 at 16:53
  • 3
    \$\begingroup\$ Have you compared the cost? I'd imagine the non-volatile ones are pricier. \$\endgroup\$ – Hearth Nov 5 '18 at 16:53
  • \$\begingroup\$ @EugeneSh I have no statistics, it is a personal observation (I updated that as a PS in the question in order to not confuse people) \$\endgroup\$ – Lavender Nov 5 '18 at 16:58
  • \$\begingroup\$ The last project I touched used sram because they reconfigure it many times for different functionality \$\endgroup\$ – PlasmaHH Nov 5 '18 at 19:08
32
\$\begingroup\$

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.

\$\endgroup\$
21
\$\begingroup\$

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

\$\endgroup\$
  • 2
    \$\begingroup\$ Actually, your first paragraph is true for a relatively limited set of FPGAs. Many flash-based FPGAs are advertised as "instant on" (a strong selling point in many applications), which means that there is no internal transfer -- the flash cells control the connections and logic directly. \$\endgroup\$ – Dave Tweed Nov 5 '18 at 21:43
  • 3
    \$\begingroup\$ From what I've seen even "instant on" devices still have to load CRAM, it just happens a lot faster (I guess due to a wider interface from the internal flash) than in parts requiring external flash. For instance the MAX10 is "instant on", but see p.28 here: intel.com/content/dam/altera-www/global/en_US/pdfs/literature/… But if you have a reference that shows a totally CRAM-less architecture I'd be interested in learning about it. \$\endgroup\$ – ajb Nov 5 '18 at 21:57
  • 2
    \$\begingroup\$ Look at Actel (now Microsemi) -- both their antifuse and flash based devices are zero-copy. \$\endgroup\$ – Dave Tweed Nov 5 '18 at 22:10
8
\$\begingroup\$

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.

\$\endgroup\$
2
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ I would argue that flash-based FPGAs may also address security concerns. See article from EEtimes regarding mitigation against attacks using differential power analysis (DPA): eetimes.com/document.asp?doc_id=1327477 \$\endgroup\$ – boink Nov 7 '18 at 11:27
  • \$\begingroup\$ @boink True, older FPGAs in particular were quite vulnerable (example), but I expect the situation to have improved by now. The article you refer to seems to advertise DPA countermeasures. \$\endgroup\$ – Dmitry Grigoryev Nov 7 '18 at 12:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.