Steve Leibson

Designing Low-Power Systems with FPGAs, Part 2

February 1, 2010 on 5:34 pm | In Design, FPGA, SOC | 1 Comment

Literally within an hour of posting my last blog entry on designing low-power systems with FPGAs, Altera’s marketing engine issued a related email and dropped it into my inbox. Altera’s email pre-announces the company’s upcoming FPGAs based on 28nm lithography. The email included the following marketing graph (with no scale) to explain the advantages of the smaller geometries for FPGA manufacture.

The first set of bars in the graph set the baseline using Altera’s 40nm devices as a reference. The next set of bars show that the feature shrink alone improves FPGA gate density by 25% and power consumption by about 12.5%. (Note: That’s my eyeball talking, not Altera’s official numbers.)

The next set of bars shows what happens incrementally when Altera takes some major logic blocks and hard-codes them. Suddenly, gate density doubles and power consumption drops by 40% compared to 40nm FPGA.

The last set of bars shows what happens when you combine the lithography shrink and hard-coded IP. Suddenly you’re getting 4x the gate density at a mere 25% of the power consumption compared to 40nm devices. (Note: I’m not sure what suddenly happened to the transceiver count, that third bar in the group, which had been constant until everything got combined in the last set. My guess is that the marketing artist who drew the graph got overzealous, cut everything 75% for visual consistency, and the proofreaders missed it. I think the number of transceivers is supposed to stay constant, based on the first three sets of bars in the graph.)

Two things to note here. First, you get a lot of bang out of hard-coded IP. Coincidentally, MIPS announced that Altera had licensed the MIPS32 architecture back in October, 2008 but Altera was mum on the subject back then. RISC processor cores make lousy targets for programmable FPGA fabrics, largely because of the routing congestion around their large register files, so processor core IP is one of the IP types that really should be hard-coded onto an FPGA. Although both Altera and Xilinx did not have much success with their first-generation FPGAs that incorporated hard-coded processor cores, that doesn’t mean they’re not going to try again and the MIPS announcement late last year telegraphed that move.

Want more proof? Last week at the Real Time Embedded Computing Conference held in Santa Clara, California, Xilinx’s Senior VP of Worldwide Marketing and Business Development Vin Ratford did more than telegraph his company’s intent to put processor cores back into FPGAs. He announced and elaborated on that intent. Xilinx will be adopting the ARM architecture and an FPGA-friendly version of ARM’s AMBA interconnect in future FPGA generations.

Make no mistake. Processors are coming to FPGAs for several reasons. First, a RISC processor core consumes between 25,000 and 50,000 gates. You can drop one of those puppies into an FPGA fabric and never see it. In essence, those transistors are “free.” That’s the nature of an FPGA’s programmable interconnect. Logic just sort of disappears.

Second, you can’t build a system without at least one processor these days. Which immediately leads to the third reason. If Xilinx and Altera truly wish to convert their “We’re taking over everything” or “All your chips are belong to us” attitudes, then the processor will just have to live on the FPGA silicon. Otherwise, the FPGA companies don’t get all of the chips. It’s as simple as that.

However, as both Altera and Xilinx discovered last time they tried this, dropping a processor core into an FPGA and making it usable is not just a matter of burying some gates into the FPGA fabric. Effective ways of connecting the processor to the programmable FPGA fabric must also exist and the software developers—who represent more than 90% of modern embedded development teams—must also be happy with the integration. You only make them happy with good development, profiling, and debugging tools.

And there’s the rub.

(It’s possible that Shakespeare’s Hamlet was indeed an embedded systems developer.)

Designing Low-Power Systems with FPGAs

February 1, 2010 on 3:47 pm | In Design, FPGA, Flash, Low-Power | No Comments

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.