Acpi

ACPI The Advanced Configuration and Power Interface (ACPI) specification combines Power Management and Plug and Play functionality for notebooks, desktops, and servers. ACPI is the keystone in Microsoft's Operating System Directed Power Management (OSPM). With OSPM, the operating system determines when to do power management, and the BIOS determines how to do power management. The two pieces work in concert to provide maximum power savings. What is ACPI? Why is ACPI important? How is ACPI designed? What are the differences between APM and ACPI? How does ACPI support Plug and Play functionality? ACPI Support and Logo Requirements How does Phoenix's ACPI BIOS solution help developers? LogoPlus ACPI Advanced ACPI ACPI Utilities ACPI Disassembler ACPI Embedded Controller Support Additional Information What is ACPI? ACPI defines hardware and software interfaces used by the operating system to manipulate the characteristics of motherboard devices. ACPI differs from APM and Plug and Play (PnP) in two fundamental ways: • The support code provided by the BIOS is not written in the native assembly language of the platform but in AML (ACPI Machine Language). • The BIOS does not determine the policies or time-outs for power management or resource management. Return to Top

Why is ACPI important? Changing from Advanced Power Management (APM) and Plug and Play (PnP) to ACPI offers many benefits including the following: 1. A cooperative "Plug and Play" environment for devices and power management for desktops, notebooks, and servers 2. An open Operating System Architecture that allows the development of ACPI for nonMicrosoft operating systems. This O/S also lets ACPI-compliant operating systems running on non-standard hardware use the ACPI interface. 3. New opportunities for product differentiation 4. Developer-defined control methods using the ACPI language ACPI support is required for NT 5.0, Windows/PC 97& 98, Server 97& 98, and OnNow Certification. Older versions of NT do not have any power management support. ACPI-compliant systems running NT can take full advantage of power savings through ACPI power management. Phoenix has an ACPI compliant BIOS, which the NT 5.0 and Win 98 development teams at Microsoft have been using for several months. The ACPI hardware interface provides two types of functionality to the operating system that previously resided in the BIOS: • Control and detection of system control events using a normal interrupt called System Control Interrupt (SCI) rather than System Management Interrupt (SMI) • Control of the system power state Return to Top

How is ACPI designed?

The following diagram from the ACPI Specification shows the various system components: (ACPI 1.0 Specification Figure 1-1, Copyright © Intel/Microsoft/Toshiba, 1996)

The areas outlined by the dotted line are described in the ACPI 1.0 specification. The system BIOS (shown as two blocks simply to indicate both the standard and ACPI functions provided) provides the details for the platform's hardware interface in one or more well-defined tables. These tables are written in ACPI Source Language (ASL) and compiled into ACPI Machine Language (AML) for inclusion in the BIOS. The ACPI software interface, implemented as a windows driver, provides the means for the operating system to find the different tables in the system BIOS. Phoenix has added a feature to the BIOS implementation that permits the tables to be dynamically modified at run time. This allows changes to the tables actually stored in the BIOS ROM before they are processed by the operating system. A system supporting ACPI requires the following components to operate correctly: • System Management Mode (SMM) - capable CPU • SMM - capable chipset • ACPI-capable support logic The final key expectation is that the operating system being run is capable of supporting ACPI. Although Microsoft operating systems will be ACPI aware in the near future, systems running UNIX, LINIX, OS/2 or other operating systems will not have ACPI support as soon. If manufacturers wish to offer any type of power management to these types of users, legacy BIOS power management must be included on the platform. Events The ACPI compliant hardware informs the operating system about power management, resource management ,and docking occurences, by creating an "event." Events generate a special interrupt called the SCI (System Control Interrupt) which is then handled by the ACPI driver. ACPI Tree All ACPI hardware and features are organized as a tree structure. The tree represents how the operating system communicates with the devices. Objects under other objects in the tree are called children. The base of the tree is called the root. When the operating system begins to cut

back power because it has detected an idle or non-use state, it does so from the bottom of the tree. This means that children are turned off before parents . Return to Top

What are the differences between APM and ACPI? Phoenix pioneered the development of BIOS-based power management which provides power savings for early notebook computers. This early power management relied on the BIOS to determine when a particular device had been "idle" long enough to reduce or remove power. With no feedback from the operating system, however, power savings were not optimized. When Microsoft introduced APM, the operating system was nominally involved in some of the power management decision making. Now, with ACPI, power management for system devices moves from the BIOS to the hardware and operating system. ACPI specifies four base power levels, with three substates for the sleeping state. • APM States: • Enabled • Standby • Suspend • Off • ACPI States: • S0=On • S1-3=Sleeping • S4=Soft Off • S5=Off The ACPI BIOS tables define what these states mean for individual devices, and the operating system determines when to move a device, or even the entire system, from one state to another. Return to Top

How does ACPI support PnP Functionality? In an ACPI implementation, the integrated Phoenix BIOS behaves as both a complete PnP (Plug and Play) BIOS and an ACPI BIOS. The system determines at boot time if it will run in PnP or ACPI mode. The ACPI BIOS contains the information necessary to communicate the hardware specific configurations and features to the operating system. Basic support for ACPI includes: • POST - ACPI table relocation/modification during the Power on Self Test • MCD - Integration during POST of Motherboard Configurable Devices • Chipset - Additional services specific to ACPI • SMM - OS Services, Global Lock, Phoenix Services, Save-to-Disk • Build - Change process to support ACPI tables, new rules, and installable options To run Windows 95 and other non-ACPI platforms, systems must support older Power Management and Plug and Play functionality. This legacy support will probably be required for at least the next two years. Although Phoenix can provide an ACPI only BIOS, an integrated ACPI/Legacy BIOS will be the BIOS of choice for most manufacturers for several years. All of the Phoenix ACPI BIOS solutions use an existing desktop, server, or notebook BIOS. All of these implementations include Embedded Controller support. Return to Top

ACPI Support and Logo Requirements Microsoft requires ACPI support since April 1, 1998. The minimum requirements are included in the ACPI Specification rev. 1.0, section 1.7 Minimum Requirements for OSPM/ACPI Systems. The section numbers shown in parenthesis below indicate the section of the ACPI Specification where these features are described. Note: Software only requirements are identified by an asterisk (*).

• • • •

A power-management timer - 3.579 MHz (4.7.2.1) A power or sleep button (4.7.2.2) A real time clock wakeup alarm (4.7.2.4) Implementation of at least one system sleep state, S1-S3 ( 9.1) - Note desktop systems may only implement S1.* • Interrupt events generate SCI's and the GP_STS (General Purpose Register Block_Status) registers are implemented (4.7.4.3) • A Description Table provided in the BIOS. (5.2)* • A user accessible fail-safe mechanism to either unconditionally reset or power off the machine. Minimal Requirements Under the PC '97 and PC '98 Design Guide criteria, minimal ACPI support is required. As the list above indicates, there are few mandatory ACPI requirements. It is essential to understand these features and the impact they make upon different PC platforms. Notebook computers operating at the minimum ACPI requirement level will lack many common features. The minimal system requirements of the ACPI specification would produce a poorly power managed notebook PC and decrease the flexibility of the system because of the lack of support for dynamic device bays and docking. Additionally, the minimal requirements do not include support for save to memory or to disk, which are standard features shipped with current notebooks. The minimal ACPI requirements also do not include support for multiple batteries. In the desktop and server markets, these minimal requirements are more realistic. The low end consumer PC's that are selling for under $1,000.00 will be prime candidates for this set of features. Minimal power management and device level OS management are completely acceptable for these platforms. Servers are also not in high demand of advanced power management and plug and play functionality as notebook PC's are. System differentiation is not expected from manufacturers that ship with only the minimal ACPI requirements supported. In order to raise the desktop and server products to the advanced power management and device flexibility of the notebook PC's, designers will need more advanced functionality to compete. Return to Top

How does Phoenix's ACPI BIOS solution help developers? Phoenix implemented the first ACPI-compliant BIOS based on the ACPI BIOS that Microsoft developed in August of 1996. This BIOS complied with Rev 0.7 of the ACPI Specification. Since then, Phoenix continues to develop new features and add enhancements required for logo certification. The architecture of Phoenix's ACPI BIOS solution reduces the burden of implementing ACPI support on a new platform by providing • A simple interface to the most common porting requirements • A strong set of core support routines • Tight integration with Motherboard Configurable Devices (MCD) Return to Top

LogoPlus ACPI LogoPlus ACPI provides ASL code that supports power management and device configuration capabilities. LogoPlus supports the following functions: • Power management timer • Either or both a power and a sleep button • Real-time clock wake-up alarm • System sleep states: S1 and S2 • SCI and GP_STS registers support in the BIOS • DSDT support in the BIOS • Fail-safe mechanism to power off or reset the system Return to Top

Advanced ACPI Advanced ACPI supports ASL code for power management and device configuration capabilities beyond that which LogoPlus offers. Advanced ACPI supports the following functions: • Power management timer • Either or both a power and sleep button • Real-time clock wake-up alarm • System sleep states: S1, S2, S3, and S4 • SCI and GP_STS registers support in the BIOS • DSDT support in the BIOS • Fail-safe mechanism to power off or reset the system • Device power management • Phoenix services for SMI handling • Device configuration - docking, PC Cards, swappable bays • ACPI embedded controller • Thermal zone management • Multiple CPU support • Multiple PCI bus support • Wake-on-event support - USB device activity and LAN or modem activity Return to Top

ACPI Utilities Phoenix provides a set of utilities to assist hardware and BIOS developers. APCI Architect Phoenix has developed a powerful design tool called the APCI Architect. This tool includes: 1. Chip set support 2. Standard component, device and bus support 3. Device and system templates 4. Built in code editor, tree viewer, device icons 5. Ease of differentiation 6. On-line Help ACPI Architect frees developers from learning the nuances of ASL and allows them to begin designing their systems immediately. ACPI Architect is used to view, modify and create ACPI System Description Tables. The table view is presented to the user in the form of an ACPI Tree and the file is stored in ACPI Architect form, *.aa. The ACPI Architect tool can generate ASL code from these *.aa files. The ASL code can then be compiled using the Microsoft ASL compiler to generate AML code for use on ACPI systems. MCD2ACPI MCD2ACPI is used for the automatic generation of ACPI configuration objects. This utility is designed to create ACPI ASL code from existing MCD structures in the Phoenix BIOS version 4.0 release 6. This should reduce the work required to build the ACPI configuration objects (PnP), for any currently implemented platform BIOS. It will automate much of the task and eliminate part of the manual coding of the ASL for already completed PhoenixBIOS 4.0 and NoteBIOS 4.0 release 6 ports. ASLPP ASL (ACPI Source Language) Preprocessor. The ACPI specification defines certain buffer formats for use with the Plug and Play section of the specification. These buffer formats are streams of bytes which detail the resources used by the device, including memory, I/O, interrupts, and DMA channels. Manually coding the buffer contents is tedious and results in ACPI code that is difficult to read. ASLPP provides a solution, extending the ASL with a preprocessor that translates Phoenix defined operations into byte streams. Return to Top

ACPI Disassembler AD displays ACPI-related tables and checks them against the ACPI 2.0 specification. Under DOS (or Windows 98/Me DOS box), these can be extracted from the system BIOS. Extract all files to a single directory. See readme.txt for usage details. Phoenix has made this utility available for your use, because of our commitment to technology leadership. Error! Hyperlink reference not valid.Error! Hyperlink reference not valid. Return to Top

ACPI Embedded Controller Support Using the in-house expertise acquired during years of keyboard controller development, Phoenix has a variety of solutions for supporting the ACPI Embedded controller. For details, refer to the Phoenix White Paper ACPI Embedded Controller - Implementation Considerations (this document is in Adobe Acrobat format. If you do not have the Adobe Acrobat reader, you can download the Reader now). The two most popular approaches to the Embedded Controller use either a single dual port controller for both Embedded Controller and Keyboard Controller (KBC), or two separate chips, one for the Keyboard Controller and one dedicated to ACPI. Embedded Controller Combined with KBC - Single Controller Solution Advantages: • Requires minimum hardware modifications to support non-ACPI and ACPI system management features in the same platform • Saves Power • Costs Less • Requires less real estate and glue logic Supported Controllers: • Mitsubishi 38813/38867/38869 • Hitachi H8/3434 • National Semiconductor PC87570 Discrete chip(s) for Embedded Controller(s) - Dual Controller Solution Advantages: • No modifications required to existing KBC firmware • Provides more I/O ports for additional system control features Supported Controllers: • Mitsubishi 38813/38867/38869 • Hitachi H8/3434 • National Semiconductor PC87570 For more information about keyboard controller support, see our MultiKey page. Return to Top

Additional Information The following documents are in Adobe Acrobat format. If you do not have the Acrobat Reader, you can download the Reader now. ACPI Architect Data Sheet ACPI BIOS Data Sheet ACPI Embedded Controller - Implementation Considerations ACPI Disasssembler