What about going back in the time when "One Time Programmable" (OTP) devices were used popularly during release? :)... In-field programability feature won't be availble then, might not be secured for IoT application where field upgradability might be an important feature but the OTP devices would have beenvery secured.
You are right on about the OTP trade-offs. Flash-based FPGAs with security features (like fabric-embedded flash configuration cells, encrypted programming bit streams with DPA resistance) can be just as secure as OTP devices in the vast majority of applications. With flash-based devices you can also support secure upgrades which will be very critical for new applications with changing standards and requirements (like IoT will be).
@DrFPGA: Thanks for the insight. Are these FLASH based FPGAs costlier than the traditional SRAM cell based FPGAs? Obviously the manufacuter would need to recover the money which is invested in developing these security features, but is the delta price premium significant? I have heard about another advantage of the FLASH based FPGAs as these have much lower static current compared to the SRAM cell based counterpart.
Flash-based devices can be less expensive at the system level since they don't need an additional external configuration device. Also the potential cost of your design being copied, stolen or reverse engineered (if you use an SRAM-based device) can be 'hidden' until it happens to you.
Lower power is another big advantage of Flash-based FPGAs since leakage current (static power) is so low compared to SRAM-based FPGAs. Some devices (like those from Microsemi) even have a 'low power' mode where the device can be put into a 'sleep mode' (similar feature to those in an MCU) without losing configuration state (since it's stored in non-volatile flash cells woven into the FPGA fabric.) Something you can't do with SRAM-based device.
You are right with the (use case dependent) advantages of flash based FPGAs. Our company is using flash based FPGAs because of the simple use, fast time between power-up and ready and there cost (industrial power-converter stuff).
But to be fair, they have also a disadvantage: As it is also true for any other digital IC, the production process needed to build embedded flash cells results in slower digital circuits than a process without flash. A and X are using 28 nm processing nodes at the moment, L is using 65 nm node with flash currently. In short (comparing same development year):
- A microprocessor without flash can be clocked higher than one with flash
This barrier is useful for a hack that replaces the original code, but what about a real-time hack that gains access to the data on it? Or, in the case of the insulin pump, gains access to a control interface to change the parameters within an otherwise-acceptable range? Securing embedded systems of this type has to be done at a number of levels. My fear is that designers will see this as a way of "solving" the security problem without doing a complete analysis.
Good point that security requires several levels to be really protected. Seems like the key element is to have a known secure starting point that can extend to other applications and security processes. A single chip solution that has all the security needed for that starting point is probably the best way to begin...
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...