As transistor technology quickly shrinks toward the vanishing point, embedded devices are taking over the marketplace. One of the key challenges of designing an embedded electronic device is maintaining reasonable power consumption in order to maximize battery life. For design engineers wanting to combine the functionality of a microcontroller with their own “special sauce” logic, a standard off-the-shelf microcontroller plus Field Programmable Gate Array (FPGA) combination has long been the preferred option.
Despite the ease of use and availability of FPGAs, they are notoriously power hungry and can quickly overwhelm the power budget of an embedded system. Transistor leakage currents lead to high static power consumption that is independent of logic implementation within the FPGA. This is simply unacceptable for designers whose products have strict power requirements. Application Specific Integrated Circuits (ASICs), on the other hand, allow full customizability and utilize low-power standard cells, achieving much better performance than possible with a similarly configured FPGA. However, ASIC design and production can be prohibitively expensive for smaller companies or those producing only a limited quantity of product. By leveraging the newly developed Metal Programmable Cell Fabric (MPCF) technology, Customizable Atmel Processors (CAP) customizable microcontrollers can dramatically reduce power consumption while allowing engineers to implement their logic in a single chip that carries the full functionality of a microcontroller plus FPGA system.
The FPGA Power Problem and CAP
While an attractive option for prototyping and emulation, FPGAs generally are not capable of achieving the same level of performance as customer-specified ASICs. With FPGAs, the benefit of re-programmability comes with the disadvantage of inefficiency. Logic utilization tends to be low due to place-and-route constraints, and unused transistors do nothing but consume extra power. Long signal paths and inefficient clock-trees add to the power hungry nature of FPGAs—a necessary evil if one requires the ability to tweak their logic. Thus, FPGAs are natural choices for new product development. However, they are less than ideal once the logic is finalized and power issues become relevant.
While offering much better power performance, ASICs have high upfront NRE costs and, depending upon complexity, right-first-time risk. Atmel’s customizable microcontrollers offer an alternative to a microcontroller-plus-FPGA combination or an ASIC. A CAP MCU is basically an ARM-based system-on-chip with a fixed selection of peripherals and a Metal Programmable (MP) block. The ARM core and peripherals on the CAP MCU constitute a fully functional, fully verified microcontroller, so risk is greatly reduced.
The MP block is based on Atmel’s newly developed MPCF cell library with routing densities comparable to those of standard cell ASIC libraries. MPCF significantly reduces the number of mask sets necessary for production—the most costly component of an ASIC NRE budget. It achieves nearly the same logic densities as comparable ASIC designs and drives down power consumption to within 10 to 15% of full custom ASICs.
When compared to FPGAs, the power saved by using CAP is considerable: designers will see over a 95% reduction in static power, and nearly a 70% decrease in dynamic power. This power efficiency, coupled with CAP’s low NRE cost in comparison to ASICs presents a very attractive alternative to microcontroller-plus-FPGA designs. This paper proposes a method for evaluating the power consumption of FPGAs and customizable MCUs.
An ARM7-based CAP7 with 450k ASIC equivalent gates was tested on a specially made test board supporting JTAG communication for manipulating the processor while running. The Xylo-L development board (www.KNJN.com) with a 500k gate (125k ASIC-equivalent gate) Xilinx Spartan 3-E XCS500E FPGA and a Philips LPC2138 ARM7 was used to test the FPGA-plus-MCU implementation. The smaller size of the Spartan FPGA would be expected to give it a power consumption advantage over the CAP customizable MCU. The Xylo-L board also has a USB interface used to load the FPGA boot configuration PROM and for manipulating the ARM. Figure 1 compares the architecture of the CAP7 with that of the Xylo-L board.
Figure 1: Comparing the architectures of CAP7 and the Xylo-L board. The MPLIB in CAP7 takes the place of an FPGA.
Both the CAP7 MCU and the Xilinx FPGA require multiple voltage sources. However, the crucial power rail to monitor is the core or internal voltage source, as any internal logic draws on this supply. Both chips run at a nominal core voltage of 1.2V, facilitating direct comparison. A digital multimeter was hooked up in series with the power supply to monitor current consumption on the CAP7 test board, which includes a banana-plug jack for 1.2V power. All power on the Xylo-L board is supplied by the 5V line on the USB jack. A trace was cut between the 1.2V regulator and the FPGA on the Xylo-L board and a multimeter connected to measure current consumption on the 1.2V rail.
To ensure a fair comparison, various factors need to be taken into account. All components of each board that could be drawing any power must be disabled in order to allow for a direct comparison between CAP7 and the FPGA. On the Xylo-L board this meant putting the Philips ARM7 into power-down mode and ensuring a low default FPGA I/O state. Additionally, an onboard EEPROM had to be programmed to tell the USB controller to produce the necessary clock for the FPGA. The available clock frequencies were 12, 24, and 48 MHz.
Initialization of the CAP7 involved ensuring all I/O were low by default and setting up the required PLLs and oscillators. It is particularly important to set MPIO81 low because it toggles the chip between platform and emulation modes. Emulation mode effectively shuts off all functionality except the ARM core, while Platform mode leaves the chip in its normal state. This was achieved by loading initialization code into the RAM on the CAP7 MCU, and stepping through it until in the proper state. CAP7 can be clocked as low as 500Hz and as high as 80MHz.
Static power is the power consumed by a device when it is not clocked. For the FPGA, a blank design was loaded into the boot PROM with no external clock lines specified. For CAP7, the main clock was set to run at 500Hz, the lowest possible value. Unfortunately the ARM7 core cannot be shut off and so the value measured is not a true static power measurement; however, 500Hz is low enough that any extra current drawn by the ARM7 core would be negligible. In any case, this would place the FPGA in the best light possible, giving an even more conservative estimate of CAP7’s power in comparison.
Dynamic power refers to the extra power a device consumes when it is clocked. To make a valid dynamic power comparison between the Spartan 3-E FPGA and CAP7, several peripherals, synthesized from a single RTL file, were implemented in both the Spartan FPGA and the CAP7 MP block and clocked at a range of frequencies. The peripheralsincluded: two USARTs (Universal Synchronous Asynchronous Receiver Transmitters), an SPI (Serial Peripheral Interface), three Timer/Counters, and an ADC Controller (Analog to Digital Converter). To measure the power consumed by CAP7 using the same peripherals, clocks to the various peripherals were either enabled or disabled by manipulating the Power Management Controller.
The FPGA modules were instantiated one at a time with no I/O connections using Xilinx’s ISE WebPack,. To keep things on an even playing field, the only clocks supplied to each peripheral were the system and configuration clocks. Analysis of the CAP7 design shows that the system and configuration clocks are the two signals enabled when a peripheral is turned on in the Power Management Controller.
For the Spartan 3-E FPGA, current draw on the 1.2V rail was measured for each of the peripheral combinations, and the static current was subtracted to produce a dynamic current value. For the CAP7 MCU, in order to eliminate the power consumption of the ARM7 core from the measurement, an “idle” current measurement was made with the chip clocked at full speed but no peripherals enabled. This idle value was subtracted from the current measured with various peripheral combinations clocked.
Current measurements of the CAP7 device and the FPGA were made at 12, 24, and 48 MHz. with a separate measurement of the CAP7 MCU at 80MHz. Due to the linear relationship between clock frequency and power consumption, data collected for the Spartan 3-E FPGA could be used to extrapolate its power consumption at 80MHz and make a direct comparison with CAP7 device. A value for percentage power reduction was calculated using the following formula:
At an internal core voltage of 1.256V, the Spartan 3-E consumed 10.71mA, resulting in a power consumption of 13.46mW. CAP7, on the other hand, drew only 274uA at the same core voltage, with a power consumption of 344uW, a 97% reduction over the FPGA. The 97% power decrease is actually conservative, as it compares a FPGA with 125 ASIC-equivalent gates to a CAP7 MCU with 450k ASIC-equivalent gates. It would take about 1 million FPGA gates to implement logic equivalent to that 450k-gate CAP7. Since static power consumption is directly related to gate-count, any FPGA larger than the one tested would consume more power and thus boost power advantage of the CAP7 MCU.
Figure 2: Comparing the static power consumption of CAP7 and the Spartan 3-E FPGA.
CAP7 reduces static power by 97%.
Eight different peripheral combinations were tested on both the Spartan 3-E FPGA and CAP7 customizable MCU. In each case, no data was transferred to or from the peripheral. Thus, the measurements indicate additional power consumed by clocking the peripherals. The combinations tested were as follows: one USART, two USARTs, one SPI, one, two, and three Timer/Counters, one ADC Controller, and a combination of the above (two USARTs, one SPI, three Timer/Counters, and one ADC Controller). Figure 3 compares the power consumed by the Spartan 3-E and CAP7 at 80MHz.1
For both the FPGA and CAP7, the individual USART peripheral block consumed the most power, at 8.01mW for the Spartan 3-E and 2.75mW for CAP7. Interestingly, while the Timer/Counter in CAP7 consumed the least power, at 1mW, the SPI was the least power hungry peripheral in the FPGA, at 4.10mW. Because of the different physical nature of MPCF compared to FPGA logic cells, the low-level implementation of peripherals vary between the two.
On average, peripherals on CAP7 MCU consumed 68% less power than those in the Spartan 3-E FPGA. The largest power saving was observed for CAP7’s ADC Controller, which posted an 84% advantage over the FPGA. A combination of the four peripherals exhibited the lowest ratio of power advantage for CAP7, but even still CAP7 proved to reduce power by over 50%.
Table 1 tallies the results for both static and dynamic power comparisons.
The MP block on CAP7 microcontroller holds a distinct power advantage when compared with the Spartan 3-E FPGA. As more peripherals are added, however, the disparity between the two becomes smaller. The well-optimized WebPack synthesis tool reuses the same logic between multiple peripheral instantiations. In CAP, each peripheral is instantiated as a distinct block with no shared logic In the FPGA implementation the peripherals only used the system and configuration clocks as inputs, and many peripheral I/O were left unconnected in the RTL. This led to optimizations during the synthesis of peripheral combinations where multiple instances of the same peripheral were used. For instance, CAP’s power advantage for one Timer/Counter is 81%, a ratio that drops with further additions of Timer/Counters. Overall, the CAP7 reduced both the aggregate dynamic and static power consumption by over 70% when compared to a Spartan 3-E FPGA-based design.
For design engineers who require low-power, CAP customizable MCUs provide a low power alternative to an FPGA-plus-microcontroller solution and a low cost-low risk alternative to a custom ASIC design. By saving over 95% in static power and almost 70% in dynamic power consumed by an FPGA, the Metal Programmable Cell Fabric (MPCF) in the CAP microcontrollers allows full customization and interface with an ARM core without fear of overwhelming a system’s power or NRE budget.
1Note that the FPGA power at 80MHz was extrapolated from data gathered at 12, 24, and 48MHz.
About the Author: Koji Gardiner is a senior at Stanford University. He will receive his Bachelor of Science degree in Electrical Engineering in 2008. He is currently applying to the co-terminal Master’s program at Stanford.