DSP System Power Management Technology

zbz0529

DSP System Power Management Technology [Copy link]

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 the techniques into a real-time operating system (RTOS) for a digital signal processor (DSP), allowing application developers to choose the specific technology that meets their application requirements. We will use the Texas Instruments (TI) DSP/BIOS? operating system as an example to show how to implement runtime power management software techniques.

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 complex power management support than simply enabling idle modes for the DSP cores. In practice, a large 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-up behavior: The processor and its on-chip peripherals are generally fully powered up at full clock rate. Inevitably, some resources are not yet needed 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 so that unnecessary power consuming devices are turned off or idle.

Idle Mode: Active power consumption in CMOS circuits occurs only when the circuits are 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, which can be idled separately to terminate active power consumption in unused modules. For example, in TI's TMS320C5510 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-off: 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 real-time deadline to be missed. Even if the new frequency is compatible with the deadline, problems may 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 for applications that require full processing power only in certain foreseeable modes. For example, a portable music player could 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 above power management techniques are already 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, the 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 the majority 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 notifying clients of power events, the power manager must support deferred completion of event processing and notify other clients while waiting for completion signals from deferred clients.
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 supplementary 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 the platform-specific Power Scaling Library (PSL), which controls 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 that is inserted into the DSP/BIOS idle loop to automatically idle the DSP cache and CPU; or configure a power saving function that is automatically invoked at boot time to idle unnecessary peripherals or subsystems.
Power Management API: PWRM provides APIs that enable developers to idle specific clock domains, 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 "will change V/F set point", "changed V/F set point", "will enter sleep mode", "exit sleep mode", "power failure", etc.) to register for notifications about the specific power events they handle.

The key feature that PWRM brings to DSP/BIOS is a "central registry" that allows 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, a client registers and is 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 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 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.
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 writes 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 through 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
Does the application need to call specific user functions at boot time to reduce power consumption?
Does the application need to reprogram the BIOS clock on frequency scaling events?
Does the application need to automatically idle the clock domain when the CPU is idle?
Voltage and frequency scaling enable/disable
CPU frequency value during import
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 take the DSP out of deep sleep mode?

The screen shot shown in Figure 3 illustrates the configuration process, showing the configuration list of the power manager general properties.

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 drop

Summarize

There are several design and runtime power management techniques that 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, this article shows how some techniques can be incorporated into D