You are in:  Design | EDA and IP

Sign-up for newsletters:

Electronics Weekly newsletters - Sign up for Made By Monkeys, Mannerisms, Gadget Master and Daily and Monthly newsletters

Read The Magazine

Latest Issue: 8 - 14 Feb, 2012
Get Electronics Weekly

How to optimise FPGA power efficiency

Friday 21 November 2008 10:45

Power consumption constraints have probably compromised more product design plans than any other factor. When a promising concept is in development, balancing that design’s great new functional goals against the sobering facts of power efficiency is often the elephant in the room. It is very likely to force a number of uncomfortable concessions in the design’s performance or functionality, but managing a design’s power budget is crucial to its success.

Managing power consumption in electronics designs is not a new problem, but the game is changing as product designs generally shrink in size, and portable products become ubiquitous. Compact battery power, small and complex designs constrained by intimate enclosures, and high-performance devices all serve to challenge a design team’s ability to meet power budgets.

Adding to this complex mix is the increasingly mainstream adoption of programmable devices such as FPGAs. An unprecedented characteristic presented by programmable devices is undefined power consumption.

Unlike traditional devices, where the internal function and power requirements are predefined, predicting how much supply current an FPGA will need is no longer a simple job of reading the numbers from data sheets. In fact, it will be largely determined by the size and type of design you program into the fabric of the FPGA.

Because an FPGA’s power demands are largely defined by the design programmed into it, the device power figures can only be predicted by tools that take into account the embedded design itself. The alternative is to wait until a prototype has been constructed, test the “real” power consumption, then revise the design in an effort to meet power budgets and performance goals. 

Available tools

To cater for this part of the process, FPGA development tools supplied by device vendors include power estimation and prediction functions. While still evolving, these systems take into account the parameters of the FPGA device, including its thermal model, and use information from your design to predict the power profile in the selected vendor’s device.

In the early prediction stage of the process you might enter basic information such as system clock frequencies and the number of function blocks in use, while a more final estimation of the power consumption can be derived from your design netlist.

In practice, this only provides a power profile for that particular embedded FPGA design, which means that the process must be rerun when the proposed design or type of device is changed. Making power efficiency comparisons between design options or devices is therefore a protracted process, and due to the partisan nature of the tools it does not support a choice of FPGAs from different vendors. There is no quick or easy way to dynamically tune the FPGA-based design’s power consumption to satisfy your design goals.

If you rely solely on the available power prediction tools when developing a product design, the hardware (and to some degree the embedded hardware design) must be defined at the beginning of the design cycle. The ability to iteratively explore power saving options during the development cycle is severely limited as a result. Potential options have to be fully and reliably investigated in the early stages of the design process, which places a heavy emphasis on the predictive capabilities of the FPGA power management tools.

Power analysis and tuning

The bottom line is that to meet an FPGA design’s power budget without significant design compromises, the predictive power analysis tools you use need all the help they can get. And from a final product perspective, FPGA power consumption is only part of the story. Power analysis and testing also needs to extend to the surrounding peripheral circuitry and support devices, so that these can also be iteratively developed towards the power efficiency goals.

A broader, more real-time approach to FPGA design can meet these needs and provide a whole new way of optimising designs within deadlines. For a start, consider an FPGA development board that features live power monitoring through a series of built-in current sensors that report back to the design software.

With this approach, the real-time power conditions of the design can be monitored, graphed and logged. Both embedded hardware and software options can now be easily explored, because power saving modes can be accurately analysed, including the surge effects of reprogramming, and a raft of other power saving techniques fleshed out in real time.

Quantified results

The next step is where the complete product development system – encompassing both the development board and design software – is also independent of FPGA vendor and device. This requires a development board that features plug-in FPGA devices cards that can be easily swapped, and this change reported back to the design software. The software in turn supports a wide range of FPGA devices through a system of driver configuration files, and backs this compatibility with libraries of pre-verified and synthesised IP blocks for all supported devices.

If this software system also incorporates embedded design capture systems that offer a high level of design abstraction, such as schematic or graphical flow interfaces, iteratively working with embedded designs becomes even easier. Embedded design options can be quickly developed or modified, FPGA devices changed, and the effect on power consumption monitored in real time on the advanced development board.

That board can also include plug-in peripheral hardware sub boards – which also include smart power sensors – allowing a full hardware implementation to be analysed from a functional and power efficiency perspective. So the need for predictive tools (power, code and circuit simulation) is vastly reduced, leaving a design “sandpit” that allows power efficiency to be accurately developed in real time throughout the product development process.

Rob Evans works for Altium

 

Comments powered by Disqus