Mixing
Why are SRAM based FPGA used more than NVM based FPGA?
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
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)
fpga embedded sram non-volatile-memory security
edited 46 mins ago
ajb
2,235521
asked 1 hour ago
Lavender
344
add a comment |Â
up vote
2
down vote
favorite
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)
fpga embedded sram non-volatile-memory security
edited 46 mins ago
ajb
2,235521
asked 1 hour ago
Lavender
344
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.
– Eugene Sh.
1 hour ago
Have you compared the cost? I'd imagine the non-volatile ones are pricier.
– Felthry
1 hour ago
@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)
– Lavender
1 hour ago
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
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)
fpga embedded sram non-volatile-memory security
edited 46 mins ago
ajb
2,235521
asked 1 hour ago
Lavender
344
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)
fpga embedded sram non-volatile-memory security
fpga embedded sram non-volatile-memory security
edited 46 mins ago
ajb
2,235521
asked 1 hour ago
Lavender
344
edited 46 mins ago
ajb
2,235521
asked 1 hour ago
Lavender
344
edited 46 mins ago
ajb
2,235521
edited 46 mins ago
ajb
2,235521
edited 46 mins ago
ajb
2,235521
2,235521
asked 1 hour ago
Lavender
344
asked 1 hour ago
Lavender
344
asked 1 hour ago
Lavender
344
344
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.
– Eugene Sh.
1 hour ago
Have you compared the cost? I'd imagine the non-volatile ones are pricier.
– Felthry
1 hour ago
@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)
– Lavender
1 hour ago
add a comment |Â
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.
– Eugene Sh.
1 hour ago
Have you compared the cost? I'd imagine the non-volatile ones are pricier.
– Felthry
1 hour ago
@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)
– Lavender
1 hour ago
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.
– Eugene Sh.
1 hour ago
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.
– Eugene Sh.
1 hour ago
Have you compared the cost? I'd imagine the non-volatile ones are pricier.
– Felthry
1 hour ago
Have you compared the cost? I'd imagine the non-volatile ones are pricier.
– Felthry
1 hour ago
@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)
– Lavender
1 hour ago
@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)
– Lavender
1 hour ago
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
4
down vote
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.
answered 1 hour ago
Dave Tweed♦
114k9137248
add a comment |Â
up vote
2
down vote
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.)
answered 29 mins ago
ajb
2,235521
add a comment |Â
up vote
0
down vote
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.
answered 19 mins ago
CapnJJ
67328
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
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.
answered 1 hour ago
Dave Tweed♦
114k9137248
add a comment |Â
up vote
4
down vote
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.
answered 1 hour ago
Dave Tweed♦
114k9137248
add a comment |Â
up vote
4
down vote
up vote
4
down vote
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.
answered 1 hour ago
Dave Tweed♦
114k9137248
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.
answered 1 hour ago
Dave Tweed♦
114k9137248
answered 1 hour ago
Dave Tweed♦
114k9137248
answered 1 hour ago
Dave Tweed♦
114k9137248
answered 1 hour ago
Dave Tweed♦
114k9137248
114k9137248
add a comment |Â
add a comment |Â
up vote
2
down vote
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.)
answered 29 mins ago
ajb
2,235521
add a comment |Â
up vote
2
down vote
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.)
answered 29 mins ago
ajb
2,235521
add a comment |Â
up vote
2
down vote
up vote
2
down vote
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.)
answered 29 mins ago
ajb
2,235521
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.)
answered 29 mins ago
ajb
2,235521
answered 29 mins ago
ajb
2,235521
answered 29 mins ago
ajb
2,235521
answered 29 mins ago
ajb
2,235521
2,235521
add a comment |Â
add a comment |Â
up vote
0
down vote
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.
answered 19 mins ago
CapnJJ
67328
add a comment |Â
up vote
0
down vote
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.
answered 19 mins ago
CapnJJ
67328
add a comment |Â
up vote
0
down vote
up vote
0
down vote
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.
answered 19 mins ago
CapnJJ
67328
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.
answered 19 mins ago
CapnJJ
67328
answered 19 mins ago
CapnJJ
67328
answered 19 mins ago
CapnJJ
67328
answered 19 mins ago
CapnJJ
67328
67328
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f405158%2fwhy-are-sram-based-fpga-used-more-than-nvm-based-fpga%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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.
– Eugene Sh.
1 hour ago
Have you compared the cost? I'd imagine the non-volatile ones are pricier.
– Felthry
1 hour ago
@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)
– Lavender
1 hour ago