In the first article of the series "Notebook Computer Makers Address Power Challenges" (Electronic Design, Dec. 15, 1997, p. 44), the historical trends concerning power were reviewed. Basically, the power dissipated in mobile-PC interiors has increased by 90% from 1994 to 1997. If the current mobile-PC power trends continue, the power will increase another 85% from 1997 to 1999. In comparison, battery capacity is projected to increase around 45% during the same time period.
If nothing is done to address rising platform power, batteries would have to be even larger to keep the same battery life we enjoy today. These power trends are making mobile-PC design more difficult, and requiring a system-level approach to solving these issues.
To address this problem, Intel Corp. has launched the Mobile Power Initiative. It is a cooperative program that unites PC industry leaders in addressing all of the areas that impact mobile-PC system power: the hardware (covered in the first article), the system power management (covered in this article), and application software (covered in a future article).
A Historical Perspective One of the first real breakthroughs in mobile power management occurred in 1989 with the introduction of Intel's SL technology (first seen on the 386SL, and still included in all of today's Intel Pentium processors with MMX technology). This technology created a new mode for the CPU called System Management Mode (SMM). SMM allows embedded code within the BIOS to slow down, suspend, or shut down part or all of the system platform, and even the CPU itself, thereby preserving and extending battery life.At a system level, there are timers for every hardware device that needs to be power managed. These timers keep track of how long it has been since the device was last accessed. When this timer reaches a preset time (usually configured by the BIOS) the device is power managed (put into a lower power state). This technology worked very well in its time, but as systems became more complex, the timers would need to be programmed based on what was happening at the system level. This lead to the next advance in system power management.
In 1991, Intel and Microsoft introduced Advanced Power Management (APM) as a means of integrating the operating system (OS) into the power management loop. This was done to allow communication between the OS and the SL power management (PM) code embedded within the BIOS. APM creates an interface between the OS and the BIOS. When APM was first introduced, it contained interfaces to address all of the known problems with timer based power management. Unfortunately, as systems continued to evolve, new interfaces became necessary to handle the changing hardware.
It soon became apparent that the industry would need to either continually update these interfaces, adding cost, complexity, and backward compatibility issues to both the BIOS and the OS, or find another mechanism to advance system-level PM. To address this, a more general control of PM was required.
The OS already deals with this type of issue through device drivers. By adding a generalized description of the hardware to the system, the OS can incorporate the PM capability. There is, however, a benefit of moving PM to a higher level. The operating system has access to more information about what tasks are running and what the user is doing, therefore it's in a better position to decide which devices should be on or off. As a result, the birth of the Advanced Configuration and Power Interface (ACPI) specification took place in January 1997.
The ACPI specification was authored by Intel, Microsoft, and Toshiba, but includes contributions from independent hardware vendors (IHV's), independent software vendors (ISV's), and original equipment manufacturers (OEM's) to ensure it met the needs of the entire industry. ACPI evolves the existing collection of PM BIOS code, APM Advanced Programming Interfaces (API's), and plug-and-play (PnP) BIOS API's into a well-specified PM and configuration mechanism. It provides support for an orderly transition from existing (legacy) hardware to ACPI hardware, and it allows for both mechanisms to exist in a single machine. Newer systems will use the ACPI, while older OSs can continue to operate with the older mechanisms.
Currently only a limited number of PC's support PM (mainly mobile PCs and desktop "green PCs"). This inhibits application vendors from supporting or exploiting PM. Moving PM into the OS makes it available on every system on which the OS is installed. The level of power savings will vary from machine to machine, but the end users and application vendors will see the same PM mechanism on all OS-directed power management (OSPM) machines.
ACPI Overview ACPI creates mechanisms for control of three basic functions: platform PM, device PM, and platform configuration. To accomplish those functions, ACPI impacts the OS device-driver model, as well as hardware on a chip set and a device level. An example of the scope of the initiative and its impact on all aspects of system design is illustrated in Figure 1.
The hardware impact lies in the ACPI register space. There are some features of ACPI that are critical enough to create fixed register space that allows the OS to interact with the hardware at the fixed location without having to wait for the OS to be fully loaded. This ability becomes important both at initial boot and when exiting a sleeping state. This fixed register space is part of the ACPI register block (Fig. 1, again).
ACPI-compliant systems will now require ACPI-compliant chip sets that meet the following requirements: They must support the ACPI fixed registers, interrupt events generating System Control Interrupts (SCI's), a PM timer, a real-time clock wake-up alarm, and an ACPI-compliant power/sleep button.
The BIOS' impact on ACPI lies mainly in the ACPI tables and control methods. The tables enable the OS to accomplish the three basic functions of ACPI. The BIOS ACPI tables provide a hierarchical description of the platform that the OS uses to perform PM and configuration. The tables are used to create the ACPI name space. The name space is, essentially, a block diagram of the system that includes the buses, devices, and control methods. Control methods are pieces of ACPI Source Language (ASL) code that perform specific functions. For instance, every device needs to have _CRS (Current Resource Settings), _PRS (Possible Resource Settings), and _SRS (Set Resource Settings) control methods to allow the OS to perform platform configuration.
The OS' impact on the ACPI is the addition of the new features that ACPI requires the OS to perform: PnP configuration support as outlined above, an ACPI ASL interpreter, and OS-driven PM support.
System States The ACPI specification defines four global or G states (Fig. 2). The G0 or Working state is the state the PC is in whenever the OS is executing code (running). This state is also where all of the device PM occurs. These device-specific, low-power states (D states) are shown by the small circles in the figure. Each device has a Device-Class PM specification that defines its corresponding D state (D0 through D3).
In general, D0 equals Device Working (full power) and D3 equals Device Off (no power) for all devices. Device PM often requires the power-managed device to change configuration between certain D States. This was one of the main reasons PnP configuration was added to the ACPI specification.
The CPU is treated as a special device, and therefore, has its own unique low-power states called C States. C0 is the CPU Working state (full power), where instructions are executed. C1 is defined as the low-power Processor state, which has small enough exit latency that the OS can use this state frequently. C1 is equivalent to a STI-HLT instruction (which automatically enables exit on interrupts and puts the CPU into a lower-power state) on an Intel-processor-based PC. C2 is a power state that provides more power savings over C1 with increased latency to enter and exit. The OS uses the C2 latency information provided in the ACPI tables to determine when C2 should be used instead of C1. C3 also is a lower-power state with increased latency. The OS, again, uses the C3 latency from the ACPI tables to determine when C3 can be used instead of C2.
The most dramatic benefits of ACPI will come from the OS' ability to dynamically and intelligently enter the most aggressive C state possible based on the current system usage. The ability to use C states as part of the System Working state (G0) was never possible before ACPI. Past PM architectures used the C states only when the CPU was idle or in System Sleeping states. ACPI C states can be used much more frequently.
The next global state is the G1 or System Sleep state. You will notice that this state is broken into four separate circles S1 through S4. S1 is defined as a low-latency sleeping state, where no system context is lost. In legacy terms, this sleeping state is comparable to a Power On Suspend.
S2 also is a low-latency sleeping state, but here the CPU and system cache context is lost. The OS is responsible for maintaining this information. Comparing it to legacy systems, S2 is a hybrid of the Power On Suspend state in which the CPU and cache are shut down to save more power.
A low-latency sleeping state, S3 loses all system context except for system memory. The OS and device drivers are responsible for restoring all of the device context except for what is in the chip set and memory, which is the hardware's responsibility. S3 is similar to legacy Suspend to RAM. S4 is the lowest-power, longest wake-up latency sleeping state supported by ACPI. To achieve the lowest possible power, it is assumed that all the devices have been powered off. S4 is similar to Suspend to Disk.
The G2/S5 state is Soft Off. The important difference about this state is that it is not a system sleeping state (i.e.: no device context is saved). From a hardware standpoint, the G2/S5 and S4 states could be identical. The difference being that when the S4 state is exited the system resumes, and when the G2/S5 state is exited the system does a full boot.
The last global state, G3 or Mechanical Off, is a state where no electrical current is running through the circuitry. This state is required to ensure a safe state in which the machine can be safely maintained/or and repaired.
The ACPI specification supports motherboard devices and other devices not covered by any bus PM specifications or device-class PM specifications. ACPI implementation allows the system designer to concentrate on providing hardware and software support for these nonstandard or value-added machine features. Only system-board-specific value-added functions need to be described through ACPI. For example, the PCI bus is defined by the PCI bus-class specification, and is natively enumerated by the operating systems PCI bus driver. Therefore, unless there are unique power or configuration functions associated with a specific device on the PCI bus, the PCI bus driver can handle both the configuration and PM of any PCI devices.
ACPI, through the use of the ACPI name space, along with OEM-provided control methods, is meant to be flexible and extensible enough to grow and adapt with the PC in the future.
End-User Benefit With ACPI, the end-user benefit is closely related to the goals of the instantly available PC concept. From the computer user perspective, the PC is off and quiet when not in use, and returns to fully operating capability when needed. Many system components, including hardware and software, must contribute in order to obtain the desired system operation. Consistent and reliable behavior can only be achieved through OSPM, which can control the power policy and coordination across a wide-range of computer types (server, desktop, mobile PC, and network computer).To achieve the desired operation, software components such as applications, drivers, and firmware (BIOS) are all affected. As an example, when the user pushes the Power button at the end of the day on an ACPI-compliant system, it will enter an S3 (Suspend to RAM) or S4 (Suspend to Disk) state. The next morning, when the user comes into work and presses the Power button, the system will resume (~ 3 to 5 s for S3 and ~ 10 to 15 s for S4) instead of rebooting (~ 1 to 2 min).
Other benefits the user will see are smarter PM and improved battery life for mobile PCs. With ACPI, mobile users will no longer have their systems prevented from entering low-power system-sleeping states because they had enabled a screen saver. ACPI will also address the other extreme: the system performing a PM feature when it is not appropriate. A good example can be found today, when giving a presentation on a mobile computer the screen will blank if a key has not been pressed within a certain time. This type of issue will no longer be a problem with ACPI.
The PnP aspects of ACPI also will benefit end users. It won't make configuration errors disappear, but it should prevent days and/or nights of unsuccessful computer upgrades.
Availability ACPI support is required as part of PC98 compliance in April 1998. Systems will begin featuring hardware support for ACPI as early as January 1998, with provisions for BIOS upgrades when Windows 98 or NT 5.0 testing has been completed. According to Microsoft, Windows 98 is currently scheduled for release in the first half of 1998, and NT 5.0 in the second half of 1998.Intel, Microsoft, and the major BIOS vendors are all providing support for OEM's to ensure there will be no hardware road blocks to the release of ACPI-compliant systems. Intel, Microsoft, and Toshiba, to help speed development of ACPI-compliant systems, have hosted ACPI Implementation Workshops. Microsoft is providing a Hardware Compatibility Test that checks for ACPI hardware compatibility. Intel provides three tools focusing on testing system power with different levels of accuracy: Intel Power Monitor, Intel Power Management Analysis Tool, and Intel Power Analyst. For more information on these tools and the Intel Mobile Power Initiative please visit http://developer.intel.com/design/mobile/intelpower.