Designing handheld, battery-powered systems that require DSP capability demands that a great deal of attention be paid to power consumption.
Selecting the DSP that delivers all the necessary computing power yet fits within a design's power budget can make or break the design's market viability or send the design back to the drawing board. Most design engineers are already painfully aware, however, that the conventional approach to estimating power consumption for a DSP produces a gross approximation at best. As such, new approaches to managing power consumption with software and estimating power consumption are needed.
Historically, a design team's first step in selecting a processor has always been to review the data sheets of the DSPs being considered. Values measured in mA/MIP or mA/MHz are usually available along with the chip's maximum IDD . This information is reported on virtually all data sheets.
The problem with this data is that power consumption is dependent on the application and the statistics quoted in data sheets don't always match up with real-world applications. Semiconductor vendors recognize this and generally disclose the basic conditions from which the power consumption figures were derived; for example, one DSP's data sheet states the following conditions: “CPU executing 75% dual MAC and 25% ADD with moderate data bus activity (table of sine waves). CPU and CLKGEN (DPLL) domains are active.”
Unless the design team's application fits this description, the data is only of use for comparing similar chips from the same manufacturer. In fact, it's likely that other semiconductor companies measure power consumption differently.
Further circumstances make the value of data-sheet numbers even more problematic for design teams with tight power budgets. For example:
- DSPs are complicated ICs that include power-saving capabilities such as sleep and power-down modes. These capabilities magnify the margin of error involved in estimates that involve a single scenario.
- Data sheets don't consider the fact that there are two components of power consumption: the processor, which operates on the core voltage supply, and the peripherals, which operate on the I/O supply.
- Design teams want to compare power consumption using different implementation approaches and platforms.
As a result of these challenges, design teams frequently find it necessary to build prototype boards and estimate power consumption results based on options such as different processors, implementation approaches, and platforms. This approach, although time consuming and expensive, at least provides more accurate data.
The methodology of estimating power consumption under different scenarios and implementation strategies is fairly well known. Data is most useful when it's segmented and derived from actual measurements. The process usually goes as follows:
- Divide the chip into subsystems
- Exercise each subsystem independently
- Use subtractive analysis to determine the contribution of each subsystem
- Determine the maximum and idle power for each subsystem
- Estimate the subsystem power consumption by interpolation
- Estimate the chip power consumption by superposition
Data from the measurements is usually put into a spreadsheet along with manufacturer data, such as core voltages. Estimates are derived by making the appropriate sums. An example of such a spreadsheet is shown in Figure 1.This approach, although an improvement over comparing data-sheet values, still leaves much to be desired. Suppose, for example, that the DSP is used primarily in a filtering application. It may be active 20% for the time and inactive 80% of the time.
Today's DSPs take duty cycles into account and this can provide a good deal of power saving. When the chip isn't active, for example, voltage may be reduced to a standby value. Frequency plays a big role in CMOS power consumption and it can be turned down when the chip isn't actively filtering.
Semiconductor vendors have put a great deal of effort into controlling power at the chip level. These features were once beyond the control of the design team. Now, designers can use software to control power consumption.
To explain how this is accomplished, let's first look at the strategies design teams can adopt to optimize performance. Inside the chip itself, system designers have access to functions such as deep-sleep modes, dynamic voltage and frequency scaling, and the ability to turn off unneeded resources when the chip is in an idle loop.
Significant power savings can also be achieved during the system boot sequence. Typically, all systems are turned on during the boot sequence. But it's advisable to switch off or idle those domains that aren't used by the application as well as domains that aren't used while the application boots.
Software code can be optimized with power consumption in mind. While it's a general rule of thumb to squeeze needed functionality into as small a code size as possible as a means of reducing memory footprint, this practice tends to use more power because the application may have to run code more often. Code also should be written to reduce the number of instruction fetches and to optimize the use of cache and internal instruction buffers. These measures all reduce the time the DSP spends in active mode and maximizes time in idle when frequency and voltage can be reduced.
Additional strategies that apply more to system-level control include:
- Selecting components carefully
- Minimizing component count
- Using internal memory first to minimize chip-to-chip power losses
- Using external memory for boot
- Powering off boot memory after startup
or low-speed, occasional access functions
Next-generation power control
Typically, the power-saving functions that semiconductor companies build into the chips operate automatically. Voltage and frequency are scaled back, for example, when the chip starts to idle. A new level of sophistication can be reached, however, if the system designers are given hooks into the DSP BIOS that allow the BIOS to take additional steps in managing power.
Automatic voltage or frequency scaling is a useful feature. But abrupt changes in the DSP's core can have unanticipated effects on peripherals. The operating system's time base may be affected by frequency scaling and some peripheral drivers may need to be informed about changes in frequency and power states to continue to operate effectively.
The OS scheduler's effectiveness can also suffer from frequency scaling. In general, coordination is needed for the system to apply safe voltage and frequency control and appropriate idling.
By creating a power-scaling library for the DSP BIOS, semiconductor vendors can provide a greater level of power consumption control and at the same time assure that the problems associated with voltage and frequency scaling can be avoided. This control can be extended beyond the chip to peripherals as well by sending messages over GPIO pins to the peripheral devices.
Figure 2 shows how power-scaling routines (PSLs in the diagram) that are called from the library can be used.
Let's assume that a DSP is running a very complex algorithm. Normally, the core would run at 1.6 V and 200 MHz as shown by the blue line on the left in Figure 2. When the algorithm isn't running, however, the frequency can be reduced to 72 MHz using the power-scaling library.
Ordinarily, the core voltage would remain at 1.6 V. But the power-scaling library can also be used to safely reduce the voltage to 1.2 V, thereby reducing power by an additional 30 mW during the time when the algorithm isn't running.
Next-generation power estimation
With all these power-consumption tools available, the designer still needs a way to estimate power of the entire system. A new approach to this challenge involves the integration of software supplied by the semiconductor vendor and hardware supplied by virtual instrumentation companies such as National Instruments.
In this approach, National Instruments' LabView monitors the chip while it's being exercised by the designer's application. Using LabView and a DSP power-optimization kit, the design team can try different implementation scenarios and tweak power consumption using GUI tools.
Design options can be explored using the kit and highly accurate power measurements can be made separately for the DSP core, DSP I/O, and total board power including flash memory, codec, and other peripherals.
Stuart Cording is an applications engineer at Texas Instruments, and Lori Vidra is TI's eXpressDSP development tools marketing manager. You can reach them at and .