DSP System Power Management Technology

In portable applications, low power consumption is a key differentiator, determining product size and operating time. For example, if you choose a portable DVD player as a distraction during a cross-ocean flight, battery life will be one of your top criteria. In this article, we will focus on many of the more commonly used software-based techniques. We will begin by explaining some of the power management techniques that can be used in embedded systems and discuss the many challenges they encounter in real-time applications. Power efficiency is determined by hardware design and component selection, as well as by software-based runtime power management techniques. The second half of this article will focus on showing how to sub-integrate techniques into real-time operating systems (RTOS) for digital signal processors (DSPs), allowing application developers to choose the specific technology that meets their application requirements. We will use the (TI) DSP/BIOS operating system from Texas Instruments (TI) as an example to show how runtime power management software techniques are implemented. Runtime Power Management Techniques

Although we discuss some specific power management techniques that can extend a standard multithreaded operating system (OS), it should be emphasized that using preemptive multithreaded OS itself can often achieve significant power savings. Real-time applications that do not utilize an OS often require the application to periodically poll an interface to detect events. This is quite inefficient from a power perspective. Using an OS allows applications to take advantage of an interrupt-driven model, where the program will begin execution when needed in response to external events. In addition, when an OS-based application has nothing to do, it will enter an idle thread, at which time a low-power operating mode can be initiated to reduce power consumption.

However, the OS needs to provide much more sophisticated power management support than simply enabling idle modes for the DSP cores. In practice, a significant amount of power is consumed by peripherals, either on-chip or external, as well as memory. It is critical that any power management approach include support for managing the power consumption of peripherals. Furthermore, the quadratic relationship between voltage and power consumption means that it is more efficient to execute code at a lower clock rate that requires a lower voltage, rather than executing at the highest clock rate and then going to idle. We will outline the many opportunities for implementing power management support in the OS:

System power-on behavior:

The processor and its on-chip peripherals are typically fully powered up at full clock rate. Inevitably, some resources are not yet needed to be powered up, or are never used during the application. For example, an MP3 player rarely uses its USB port to communicate with the PC. At startup, the operating system must provide a mechanism for the application to throttle the system, shutting down unnecessary power consuming devices or idling them.

Idle mode:

Active power consumption in CMOS circuits occurs only when the circuit is clocked. Unnecessary active power consumption can be eliminated by turning off unneeded clocks. Most DSPs incorporate mechanisms to temporarily terminate active CPU power consumption while waiting for external events. "Idle" of the CPU clock is usually triggered by a "stop" or "idle" instruction, which is called when the application or operating system is idle. Some DSPs partition multiple clock domains, and these domains can be idled separately to terminate active power consumption in unused modules. For example, in TI's TMS320C55 10 DSP, six clock domains can be selectively idled, including the CPU, cache, DMA, peripheral clocks, clock generators, and external memory interfaces.

In addition to supporting idling the DSP and its on-chip peripherals, the OS must also provide mechanisms for idling external peripherals. For example, some codecs have built-in low-power modes that can be activated. One challenge we face is peripherals like watchdog timers. Normally, watchdog timers should be serviced at predefined intervals to avoid their activation. Thus, power management techniques that slow down or halt processing can inadvertently cause application failures. Therefore, the OS should enable applications to disable such peripherals during sleep mode.

Power outage:

Although idle modes eliminate active power consumption, static power consumption occurs even when circuits are not switching, primarily due to reverse-bias leakage. If a system includes a block that does not need to be powered at all times, power consumption can be reduced by having the operating system power up the subsystem only when needed. Until now, embedded system developers have put very little effort into minimizing static power consumption because CMOS circuits consume very little static power. However, new, higher-performance transistors have significantly increased current leakage, requiring new attention to reducing static power consumption and more sophisticated sleep modes.

Voltage and frequency scaling (frequency scaling) Effective power consumption scales linearly with switching frequency, but quadratically with supply voltage. Running an application at a lower frequency does not save much power compared to running it at full clock frequency and going to idle. However, if the frequency is compatible with the lower operating voltage available on the platform, then we can potentially achieve significant savings by reducing the voltage, precisely because of the quadratic relationship mentioned above. This has also led to a lot of academic research on how to save power through voltage scaling.

Although voltage scaling is a potentially very tempting way to reduce power consumption, we should be careful when using it in real-world applications. This is because we need to fully understand whether the system can still meet its real-time deadlines. Reducing the voltage (and therefore the CPU frequency) will change the execution time of a given task, potentially causing the person to miss the real-time deadline. Even if the new frequency is compatible with the deadline, problems can still arise if the waiting time between switching frequencies and voltages is too long. Factors that affect waiting time include the following:

* Time required to reprogram the regulator

* Can the DSP continue to execute any other code during the voltage change?

The need to reprogram peripherals, such as serial ports or external memory interfaces, to interface with peripherals that receive different clock sources. For example, a reduction in the CPU clock rate may require a reduction in the number of wait states for accessing external memory.

The possibility of reprogramming the timer used to generate the operating system clock tick would affect the absolute correctness of the operating system's time base.

Although the actual latency of voltage scaling will vary depending on the DSP selected and the number of peripherals that need to be reprogrammed, in many systems the latency is only a few hundred microseconds or even a few milliseconds. This will make voltage scaling impractical in many real-time applications. Despite the above weaknesses, it is still possible to take advantage of voltage scaling in applications that require full processing power only in certain foreseeable modes. For example, a portable music player may use the DSP for MP3 decoding and general control processing required by the user interface. If only the MP3 decoding requires the full clock rate, the DSP can reduce its voltage when performing user interface functions and only operate at full power when music data begins to flow to the DSP.

Implementing Power Management in a DSP RTOS

A subset of the power management techniques described above have been included in RTOS for DSPs. To better illustrate how to build power management into an RTOS, we will discuss the implementation in more detail.

As we have seen in the previous discussion, the way to reduce power consumption in a particular system depends mainly on the nature of the application and the options provided by the DSP and surrounding peripherals. Therefore, the key design goals are efficiency and flexibility. Although the implementation described below is for a specific RTOS, its concepts can be easily applied to other operating systems or even to application environments without an operating system.

Power Supply Manager (PWRM) Requirements

The key requirements for the first power manager implementation are as follows:

* Power management actions are application-initiated, not OS-initiated. The primary decision to change the DSP operating mode or functionality is made by the application and driven by PWRM calls. However, the OS can (and should) automatically take actions to save power, as long as the action does not impact the application. For example, the PWRM should automatically idle the CPU clock when the CPU is idle.

* Power management actions are triggered by the control portion of the application, but should be transparent to most of the application code. For example, high-value, optimized DSP algorithms do not have to be rewritten to work in a managed power environment.

* The power manager must support voltage and frequency (V/F) scaling and must also take full advantage of chip idle and sleep modes.

* The power manager must coordinate the handling of power events throughout the application (such as application code, drivers, and the operating system itself) and notify clients that have registered to be notified when specific events occur.

* Power management features must be available in any threaded environment and must also be available to multiple instances of a particular client (such as multiple instances of a codec driver).

* When issuing power event notifications to clients, the power manager must support delayed completion of event processing and notify other clients while waiting for the completion signal from the delayed client.

* The power manager must be scalable and portable to different platforms with different capabilities.

Power Management Module (PWRM)

A power manager called PWRM is added as a subsidiary module of DSP/BIOS, as shown in Figure 1.

Conceptually, the Power Manager is parallel to the kernel; it is not another task in the system, but exists as a set of APIs that execute in the application control thread and in the context of the device driver. No kernel modifications are required to incorporate the PWRM; however, on platforms where the CPU clock is tied to the OS timer clock, the DSP/BIOS clock module (CLK) has additional routines to allow it to adjust the OS clock (as a client of the PWRM) based on frequency scaling events. The PWRM writes and reads clock idle configuration registers and interfaces directly to the DSP hardware through platform-specific Power Scaling Libraries (PSLs) that control the CPU clock rate and voltage regulation circuitry. The PSL isolates the PWRM and the rest of the application from the low-level implementation details of the frequency and voltage control hardware.

The role of the power manager is to manage all power-related issues in DSP/BIOS applications, both statically configured by application developers and dynamically called at runtime:

Static configuration of power management operations. PWRM enables the DSP/BIOS configuration tool to provide design-time options for some power management operations. For example, developers can configure an idle function to be inserted into the DSP/BIOS idle loop to automatically idle the DSP cache and CPU; or configure a power saving function to be automatically invoked at boot time to idle unnecessary peripherals or subsystems.

Power Management API:

The PWRM provides APIs that enable developers to idle specific clock domains to invoke custom sleep modes and dynamically change the operating voltage and frequency of the DSP CPU. With the new API family, applications can also specify whether voltage and frequency should be scaled simultaneously, whether execution can continue during voltage reduction transitions, and query V/F set point properties and wait times.

Registration and notification of power events:

To coordinate V/F scaling, sleep mode, and other power events throughout the application, PWRM introduces a new registration and notification mechanism that enables entities (such as application code, peripheral drivers, packaged content, and operating system clock modules) that handle power events (such as "V/F set point will change", "V/F set point has changed", "will enter sleep mode", "exit sleep mode", "power failure", etc.) to register for notifications on the specific power events they handle.

The key feature that PWRM brings to DSP/BIOS is the "central registry" that allows the code that handles power events to register for notifications of specific power events that it needs to be notified of, and to unregister when it no longer needs notifications. Figure 2 shows the registration and notification concept:

Figure 2 Power event notification concept

In this example, the client registers and gets notified about specific V/F power scaling events. The numbered steps in the diagram are:

The application code registers to be notified of V/F set point changes. For example, the DSP requires different external memory interface (EMIF) settings for different set points, so the application registers can control the power management manager (PWRM) code, and the EMIF settings can change as the set point changes. As part of the registration, the application code tells the PWRM when the event occurs: the specific notification function to call; the different customer-specific parameters passed as part of the notification; and the V/F set points that the control code can operate on (so that the PWRM does not try to initiate an unsupported set point change).

The DSP/BIOS codec driver using the serial port and DMA transfer data registers will be notified of V/F set point changes. In this application, no MP3 decoding occurs at the lower V/F set points. Therefore, when MP3 playback is not being performed, the driver can idle the serial port and DMA clock domains and set the external codec to low power mode.

Similarly, the File System Manager also registers with the PWRM to be notified of set point changes as it manages the storage media.

The application decides to change the V/F set point (such as a change in MP3 player mode) and calls the PWRM API to initiate the set point change.

The PWRM confirms that the new set point is enabled for all registered customers and then notifies all registered customers of the pending set point change.

The PWRM makes calls to the PSL to change the voltage and frequency set points. To safely change the V/F set points, the PSL will write the appropriate clock generation and voltage regulation hardware.

After a set point is changed, the PWRM will notify the client that a set point change has occurred.

Power Manager Configuration

DSP/BIO implements both static and dynamic creation of kernel objects. For example, tasks can be created statically at design time using the graphical configuration tool, or dynamically at run time using the TSK_create() API call. Many of the configuration parameters of the power manager involve design time decisions; therefore, static configuration of power management is added to the configuration file used by the DSP/BIOS graphical configuration tool. The following power manager parameters are statically configurable:

* Power Manager Enable/Disable

* Whether the application needs to call specific user functions when importing to reduce power consumption

* Whether the application needs to reprogram the BIOS clock on frequency scaling events

* Whether the application needs to automatically idle the clock domain when the CPU is idle

* Voltage and frequency scaling enable/disable

* CPU frequency value when importing

* CPU voltage value during import

* Voltage scaling enable/disable

* Does the application need to wait when the voltage drops?

* Does the application need to idle the clock domain when the DSP enters deep sleep state?

* Which interrupts can exit the DSP from deep sleep mode

The configuration process is reflected in the screen shot shown in Figure 3, which shows the configuration list of the general properties of the power manager.

Figure 3 Configuring the general properties of the power manager

In addition to the power manager static configuration properties, the following properties are dynamically reconfigured at runtime through the exported power manager API:

* When the CPU is idle, the clock domain is automatically idle

* Enable voltage scaling along with frequency

* Waiting for voltage to drop

Summarize

Several design and runtime power management techniques can be deployed in real-time embedded systems. In general, some techniques are applicable to a wide range of systems, while others are only applicable to specific applications. For example, it shows how some techniques can be integrated into the DSP/BIOS RTOS system, while application developers can also choose the appropriate technology for their application requirements.