Actel has published a White Paper discussing low-power aspects of using FPGAs. It should not surprise you that the White Paper’s points and conclusions favor Actel’s Flash-based FPGAs over SRAM-based FPGAs from other vendors but that bias should not stop you from extracting some good meat from the document.
The first important point from the White Paper: designers considering the use of an FPGA have decided not to take the ASIC/SOC route for one of several reasons. Carefully tailored ASICs and SOCs should always deliver the lowest unit-cost system chip with the lowest power—but there’s always a cost. That cost involves a large and complex design process that requires a substantial team of trained silicon designers, a big stack of expensive ASIC design tools, expensive fabrication masks, and weeks or months of fabrication delay after tapeout. Contrast that with no up-front NRE costs for an FPGA, inexpensive FPGA design tools, and no need to be familiar with the arcane world of chip design when using an FPGA to implement a system. For system designs shipping in lower volumes, FPGAs are mighty attractive.
Once you decide to use an FPGA, you must then decide on the FPGA technology you’ll use (SRAM-based, Flash-based, or antifuse-based) and you must pick an FPGA vendor. Given that you’ve selected to take the FPGA route, there are five components of device power consumption for you to examine when evaluating different FPGA technologies:
- Static power (leakage)
- Dynamic power (frequency dependent)
- Power-up (or inrush power)
- Configuration power
- Sleep-mode power
The total energy consumed by the FPGA (which is the most important design criteria for battery-powered designs) combines all five of these power components over time. It’s here that the Actel White Paper unsurprisingly starts to make the case for Actel’s Flash-based FPGAs, but again, the information provided in the White Paper is instructional.
Figure 1 shows a startup scenario for SRAM-based and Flash-based FPGAs. Power is applied to the system at T0 (time = 0) on the graph. As the input power supply voltage rises from zero volts, the SRAM-based FPGA draws a large inrush current as its SRAM configuration array powers on. Is the inrush current really as large for an SRAM-based FPGA as shown in Figure 1? Is it as small for a Flash-based FPGA as shown in Figure 1? Well, there’s no scale (making Figure 1 a marketing graph), so who’s to say? What you should get from this point is that you need to find out what that inrush current is for the FPGA’s you’re considering.
Figure 1: FPGA power consumption for power-up stage
Something else of interest is happening in Figure 1 and you might be tempted to misinterpret it. The blue line representing the Flash-based FPGA power consumption starts to ramp up well before the purple line representing the SRAM-based FPGA. At first glance, the lines make it appear that the Flash-based FPGA will consume more power over time than the SRAM-based FPGA. However, what the curves actually show is that the SRAM-based FPGA needs time to download configuration data into its configuration SRAM while the Flash-based FPGA starts to perform its system duties more quickly because there’s no configuration overhead.
Figure 2, another marketing graph, compares the power consumption of an SRAM-based FPGA with that of a Flash-based FPGA. Keep in mind that this is a marketing graph comparing two unspecified FPGAs which may or may not have similar gate counts performing some sort of unspecified workload. However, what’s shown that is useful is that you do need to consider the FPGA’s power consumption in these various operating phases and you need to weight the power use by the amount of time your system will spend in each phase to arrive at an estimate for battery life.
Figure 2: FPGA power consumption in various operating stages
One final note of interest in the Actel White Paper is that a Flash-based FPGA configuration cell is smaller than an SRAM-based configuration cell, so leakage currents are also smaller for Flash-based FPGAs. This point appears in the “Static” sections of Figure 2.
