Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
  • G06F1/26—Power supply means, e.g. regulation thereof
  • G06F1/32—Means for saving power
  • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode

Definitions

• the present invention relates to a novel system for providing a decoupled power management state. More specifically, the present invention provides a system, e.g., a computer system or network, with one or more alternate power management states that allow resources of a host system to remain operational while the operating system (OS) is in a sleep mode or state.
• OS operating system
• ACPI Advanced Configuration Power Interface
• One goal of ACPI is to unify power management in the operating system of the computer, thereby allowing inexpensive power managed hardware to support very elaborate power management policies.
• centralizing power management in the OS may provide some advantages, it also creates disadvantages as computing devices are increasingly deployed in a network environment, especially where real-time responses are prized.
• computers in a home environment can be networked in such a manner that resources in each computer can be shared, e.g., a host computer having a large storage device having a plurality of stored video and/or streams or a host computer having a DVD drive.
• a remote computer To access the stored video and/or streams or the DVD drive, a remote computer must communicate its request to the OS of the host computer. Unfortunately, if the host computer has been turned “on” for some time, the power management functions of the OS would likely have placed the system in a power saving state. In order to service the request of the remote computer, the host computer must be revived or awaken to an operating state which may require a substantial amount of time.
• the present invention is a novel method and apparatus for providing a decoupled power management state. More specifically, the present invention decouples the operating system's perspective of the power management state from that of the actual hardware state of a host resource. Namely, the resources of a host computer can still operate and provide functionality while the host operating system is "off', while still providing power saving to the host system and user.
• the general function of the operating system is to interface the user to the host resources for general applications.
• the host resources can service the user or other external clients (e.g., networked operations) without the involvement of operating system (e.g., playing a CD or a DVD).
• decoupled power management is accomplished through BIOS intervention when entering and exiting power management (PM) states by allowing the BIOS to be called where states are saved/restored without interference from the OS.
• PM power management
• real-time state management and control of peripherals of the host computer can be realized even though the system may be in a temporary "off state. Having to wait for the operating system to boot or a state to be restored will defeat most applications that require real-time responses.
• FIG. 1 illustrates a block diagram of a system for providing a decoupled power management state of the present invention
• FIG. 2 illustrates a block diagram of the relationship between software and hardware components of a system for providing a decoupled power management state.
• FIG. 1 illustrates a block diagram of a system 100 for providing a decoupled power management state of the present invention.
• FIG. 1 illustrates a system 100 of the present invention as implemented using a general purpose computer.
• the computer system 100 comprises a processor (CPU) 110, a memory 120, e.g., random access memory (RAM) and/or read only memory (ROM), a plurality of power state control registers 140, various input/output devices 130, (e.g., storage devices, including but not limited to, a tape drive, a floppy drive, a hard disk drive, a compact disk (CD) drive or a digital videodisk (DVD) drive, a receiver, a transmitter, a speaker, a display, a speech signal input device, e.g., a microphone, a keyboard, a keypad, a mouse, an A/D converter, and the like) and a basic input/output system (BIOS) 150.
• BIOS basic input/output system
• the power state control registers 140 can be implemented as one or more physical devices (e.g., registers) that are coupled to the CPU 110 through a communication channel.
• the power state control registers 140 can be represented by one or more software applications (or even a combination of software and hardware, e.g., using application specific integrated circuits (ASIC)), where the software is loaded from a storage medium, (e.g., a magnetic or optical drive or diskette) and operated by the CPU in the memory 120 of the computer.
• the power state control registers 140 can be represented by Field Programmable Gate Arrays (FPGA) having control bits.
• the power state control registers 140 (including associated methods and data structures) of the present invention can be stored on a computer readable medium, e.g., RAM memory, magnetic or optical drive or diskette and the like.
• power state control registers 140 comprise OS controlled standard registers 140a (e.g., standard ACPI registers) and power state abstraction registers 140b of the present invention.
• the OS controlled standard registers 140a can be ACPI status/enable registers that form the event model for power management.
• the state abstraction registers 140b are used in the present invention to abstract the state(s) stored in the standard registers to another system or device defined state.
• the BIOS 150 can be perceived as built-in software that determines what a computer can do without accessing programs from a disk. On personal computers, the BIOS contains all the code required to control I/O devices, e.g., the keyboard, display screen, disk drives, serial communications, and a number of miscellaneous functions.
• the BIOS is typically deployed as a ROM chip that resides within the computer (e.g., known as a ROM BIOS). This ensures that the BIOS will always be available and will not be damaged by disk failures. It also ensures that it is possible for a computer to boot itself. However, in the present invention, the BIOS 150 in conjunction with the power state control registers 140 provide a decoupled power management approach that is described in detail below.
• host system 100 can be deployed in a network. As such, host system 100 may receive requests from external clients on path 105 to access its resources.
• FIG. 2 illustrates a block diagram of the relationship between software and hardware components of computer system 100 for providing a decoupled power management state.
• software applications 210 communicate with host resources via host operating system 220.
• the host OS 220 will direct the system to enter into a power management state by communicating with the power state control registers 140.
• the power state control registers 140 in conjunction with the BIOS 150 will cause the host resources, e.g., hardware devices such as disk, CD, or DVD drives to enter a particular power management state.
• the power state control registers 140 in conjunction with the BIOS 150 will only selectively comply with the requests of the host OS 140.
• the hardware devices are not placed into a power management state as directed by the OS and instead are left in an operational state.
• the host OS is not informed of this non-compliance and, in fact, the active states of the hardware devices are hidden from the host OS.
• a computer system (or more appropriately, its operating system) is often implemented with some form of power management policy, e.g., in accordance with ACPI or other power management standards.
• the purpose of these power management standards is to unify power management in the operating system of the computer, thereby allowing inexpensive power managed hardware to support very elaborate power management policies.
• ACPI specifies a plurality of global states (Gx states, i.e., G0:Working; G1 :Sleeping; G2:Soft Off and G3:Mechanical Off), a plurality of sleeping states (Sx states) and a plurality of processor power states (Cx states).
• S1 Sleeping State (Standby): The S1 sleeping state is a low wake latency sleeping state. In this state, no system context is lost (CPU or chip set) and hardware maintains all system context.
• S2 Sleeping State The S2 sleeping state is a low wake latency sleeping state. This state is similar to the S1 sleeping state except that the CPU and system cache context is lost (the OS is responsible for maintaining the caches and CPU context). Control starts from the processor's reset vector after the wake event.
• S3 Sleeping State (Suspend to RAM): The S3 sleeping state is a low wake latency sleeping state where all system context is lost except system memory. CPU, cache, and chip set context are lost in this state. Hardware maintains memory context and restores some CPU and L2 configuration context. Control starts from the processor's reset vector after the wake event.
• S4 Sleeping State (Suspend to Disk): The S4 sleeping state is the lowest power, longest wake latency sleeping state supported by ACPI. In order to reduce power to a minimum, it is assumed that the hardware platform has powered off all devices. Platform context is maintained.
• S5 Soft Off State The S5 state is similar to the S4 state except that the
• OS does not save any context.
• the system is in the "soft" off state and requires a complete boot when it wakes.
• Software uses a different state value to distinguish between the S5 state and the S4 state to allow for initial boot operations within the BIOS to distinguish whether or not the boot is going to wake from a saved memory image.
• Processor power states are processor power consumption and thermal management states within the global working state, GO.
• the Cx states are defined in the ACPI as follows:
• CO Processor Power State While the processor is in this state, it executes instructions.
• C1 Processor Power State This processor power state has the lowest latency. The hardware latency in this state must be low enough that the operating software does not consider the latency aspect of the state when deciding whether to use it. Aside from putting the processor in a non-executing power state, this state has no other software-visible effects.
• C2 Processor Power State The C2 state offers improved power savings over the C1 state. The worst-case hardware latency for this state is provided via the ACPI system firmware and the operating software can use this information to determine when the C1 state should be used instead of the C2 state. Aside from putting the processor in a non- executing power state, this state has no other software-visible effects.
• C3 Processor Power State The C3 state offers improved power savings over the C1 and C2 states. The worst-case hardware latency for this state is provided via the ACPI system firmware and the operating software can use this information to determine when the C2 state should be used instead of the C3 state. While in the C3 state, the processor's caches maintain state but ignore any snoops. The operating software is responsible for ensuring that the caches maintain coherency.
• Gx, Sx and Cx states are further defined in greater detail in the ACPI standard, which is herein incorporated by reference.
• the different sleeping states as defined in the ACPI provide different degrees of power savings and associated latency in reviving the system.
• the time necessary to have the system awaken may range from over one minute (e.g., S5 with the greatest amount of power savings) to a few seconds (e.g., S1 with the least amount of power savings).
• S5 with the greatest amount of power savings
• S1 with the least amount of power savings
• the system is in a sleep state, its resources are inaccessible without first reviving the computer system, i.e., communicating with the OS of the computer system 100.
• there is a dichotomy between the need to save power and the need to access the resources of the host computer without the associated latency penalty.
• the present invention provides a decoupled power management approach, where the operating system of the host computer is deceived into believing that its power saving policies have been implemented.
• the hardware states are intentionally hidden from the host operating system, in direct contrast to the ACPI specification that promotes operating system- directed configuration and power management. Namely, when the host operating system directs the system into one of the predefined sleeping states as defined by the ACPI standard, the system translates that request in accordance with the instructions stored within the present power state control registers 140. In some instances, the operating system's power management requests are followed, whereas in other instances, the operating system's power management requests are ignored in part or in whole. The exact translation of the operating system's power management requests into alternate power management states are described below with reference to TABLE 1.
• power state control registers 140 are deployed. These eight 32-bit power state control registers control how each system power state is executed. The BIOS 150 can modify these as needed, but at a minimum, the BIOS will set up these registers whenever the computer system powers on from a mechanical power off. Table 1 labels these eight registers as (MCP_ACPI_xx_CTL). For each power state control register, Table 1 provides an operating system requested state (e.g., processor power state Cx or a sleeping state Sx), a state description, and the actual state that is implemented by the present invention. It should be noted that not all the processor power states (e.g., CO and
• the operating system's requested state is C2, where the clock is stopped and the cache is still snoopable. Responsive to this OS request, the present invention complies and sets processor power state to C2.
• the operating system's requested state is C3, where the CPU is in a sleep mode and the cache is not snoopable. Responsive to this OS request, the present invention does not comply and sets the processor power state to C2 instead.
• the operating system's requested state is C4 or
• VID/FID where the CPU may request a voltage/frequency change. Responsive to this OS request, the present invention does not comply and sets the processor power state to C2 instead. Alternatively, the present invention may comply in part, e.g., setting the processor power state to C2, but allowing the voltage/frequency change to be effected.
• the operating system's requested state is S1 , where the system is in standby. Responsive to this OS request, the present invention complies and sets sleeping state to S1. ln row five of Table 1 , the operating system's requested state is S3, where the system is suspended to RAM, i.e., where the CPU saves all its states to RAM memory. Responsive to this OS request, the present invention does not comply and sets the sleeping state to S1 instead. In row six of Table 1 , the operating system's requested state is S3, where the system is suspended to disk, i.e., where the CPU saves all its states to a disk. Responsive to this OS request, the present invention does not comply and sets sleeping state to S1 instead.
• the operating system's requested state is S5, where the system is in soft off. Responsive to this OS request, the present invention complies and sets sleeping state to S5.
• the operating system's requested state is a system specific state.
• the eighth register is implemented as an extra or optional register to address a system specific state or to allow state expansion.
• These power state control registers 140 in effect, drive a power down state machine. Namely, the state machine based off the register for each state, will decide what is to be done in accordance with instructions stored within each register.
• the information stored within each 32-bit register is disclosed in Table 2 below.
• SLP_S5 PLY This controls the delay from PCI_RST# activation to SLP_S5# activation.
• SLP_S5# is typically used to turn off the memory power.
• SLP_S5 and SLP_S3 can both be programmed with independent delays from PCI_RST#. This allows either SLP_S5# or SLP_S3# to assert first. On deassertion, the delay for SLP_S5# is still set by the SLP_S3_DLY, and SLP_S3# and SLP_S5# will deassert simultaneously. See the Activation Delay table below.
• CPUSLP EN This controls CPU SLP# activation.
• CPU_SLP# activation if enabled, is simultaneous to LDT_STP# activation.
• CPU_SLP# is typically used to put the CPU into a lower power state than possible with STPCLK#.
• -6 LDTSTP PLY This controls the delay from the Stop Grant Special cycle (the CPU's response to STPCLK# assertion) activation to LPT_STP# activation.
• LDT_STP# is used to disconnect the LDT Bus. See the Activation Delay table below.
• -3 STPCLK PLY This controls the delay from the power management command to the activation to STPCLK# activation.
• STPCLK# is used to put the CPU in a Stop Grant state. See the Activation Delay table below.
• Table 2 Bit 31 of each power state control register is reserved. The use of this particular bit can be implemented at a later time pursuant to a specific application.
• Bits 30-28 define a system management action field (SMAF). This field is used to optionally inform the CPU as to what actions are currently being taken.
• SMAF system management action field
• PME_WAK field This field is used to define whether the system will wake from a power management event (PME) event or PME input. PMEs are use in Sx states to signal that the system should be woken up. In one embodiment, the PME_WAK field is set to "1 " for Sx states and "0" for the Cx states.
• Bit 26 defines a SMI_WAK field. This field is used to define whether the system will wake from a system management interrupt (SMI) event. SMIs are used whenever it is desirable to give control to the SMM routine and take control away from the OS. This field is used to wake the CPU for an alternate function that is not defined in the ACPI standard. For example, one may use SMI# wake event as an alternative to PMEs.
• SMI system management interrupt
• Bit 25 defines an IRQ_WAK field. This field is used to define whether the system will wake from an interrupt event. Namely, this field is used to wake the CPU for an alternate function that is not defined in the ACPI standard, e.g., waking the CPU with an interrupt.
• Bit 24 defines a ARB_REQ_WAK field. This field is used to define whether the system will wake from a Bus Master Request event.
• a Bus Master Request event is when any bus master that is not the CPU, wants to use the bus.
• the ACPI standard uses this in C3 if it has not flushed the cache to system memory. This wakes the CPU up so that it's cache can be snooped. Namely, this field is used to wake the CPU for an alternate function that is not defined in the ACPI standard.
• Bits 23-22 define a resume delay (RSM_DLY) field. This field is implemented to define a period of time that must elapse before the CPU is awaken, i.e., not waking the CPU too early. This field can be used to address effects caused by implementing power saving operations, e.g., lock up may occur in a power supply if power is switched off and on too quickly and so on.
• Bits 21-19 define a SLP_S5_DLY field that controls power supply rails. Specifically, this field controls the delay from a PCI reset (PCI_RST#) activation to SLP_S5# activation, where SLP_S5# is typically employed to turn off the main memory power.
• Bits 18-16 define a SLP_S3_DLY field that controls power supply rails.
• this field controls the delay from a PCI reset (PCI_RST#) activation to SLP_S3# activation, where SLP_S3# is typically employed to turn off the main power supply rails, i.e., turning the power off to the CPU.
• PCI_RST# PCI reset
• SLP_S3# is typically employed to turn off the main power supply rails, i.e., turning the power off to the CPU.
• Bits 15-13 define a PCIRSTJDLY field that controls power supply rails. Specifically, this field controls the delay from a SLP_S3# activation to a PCI reset (PCI_RST#) activation, where PCI_RST# is employed to reset all the system logic. Namely, this field defines whether to put the system into a reset.
• Bits 12-10 define a SLP_S1_DLY field that controls power supply rails. Specifically, this field controls the delay from a LDT_STP# activation to SLP_S1# activation, where SLP_S1# is typically employed to power an LED that indicates whether the motherboard is asleep or not.
• the LDT_STP# is a pin that directs whether the CPU bus is to be disconnected or not. LDT is also know as the HyperTransport Bus. It is a point-to-point bus designed by AMD. The LDT_STP# pin causes this bus protocol to "stop”.
• Bit 9 defines a CPUSLP_EN field that controls the CPU S
• the ACPI defines a sleeping/wake logic that is controlled via two bit fields: Sleep Enable (SLP_EN) and Sleep Type (SLP_TYPx).
• SLP_EN Sleep Enable
• SLP_TYPx Sleep Type
• Bits 8-6 define a LDTSTP_DLY field that controls the delay from the Stop Grant Special cycle (the CPU's response to STPCLK# assertion) activation to LDT_STP# activation.
• LDT _STP# is used to disconnect the LDT Bus.
• Bits 5-3 define a STPCLK_DLY field that controls the delay from the power management command to the activation to STPCLK# activation, where STPCLK# is used to put the CPU in a Stop Grant state.
• Bit 2 defines an arbiter override (ARB_OVR) field that is used to allow devices to still access system memory for non-coherent accesses even though the Arbiter is Disabled.
• ARB_OVR arbiter override
• PM2_CNT_BLK register block in accordance with the ACPI standard contains a single bit for the arbiter disable function. Namely, this bit is implemented to override that bit.
• Bit 1 defines a system management interrupt (SMI) enable field. This field determines whether a SMI# is caused.
• SI system management interrupt
• Bit 0 defines a state enable (ST ⁇ N) field. This bit must be set for the rest of the bits in this register to be executed, except for the SMI bit which is operated on regardless.
• each power state control register 140 is only illustrative in a particular embodiment. Those skilled in the art will realize that these fields can be implemented in part (i.e., implementing only a subset of the above fields), in different orders, in different sizes or using different parameters than those disclosed above.
• each power state control register 140 is implemented in anticipation of being deployed in an ACPI compliant system.
• those skilled in the art will realize that the present invention can be adapted so that it can be deployed in a system that may comply with other power management standards.
• the present invention is implemented using state abstraction registers as disclosed above, the present invention is not so limited. Namely, the abstraction can be stored in fixed logic or it can even be read from a ROM when needed.
• the main approach of the present Invention is to abstract the standard registers to another system or device defined state.
• One advantage of the present invention is that the power state control registers 140 can be deployed in a system where the host OS presumes that a particular power management standard, e.g., ACPI, is being followed. In this manner, an alternate power management scheme can be implemented using the present invention without the need to modify the host OS.
• a computing system manufacturer may desire an alternate power management scheme, while still being able to use standard operating systems without having to address incompatibility issues.
• Table 3a discloses specific standard settings for various bits of the power state control registers in accordance with processor power states (Cx) and sleeping states (Sx). In other words, these settings would be ACPI compliant.
• Table 3b discloses modified settings for various bits of the power state control registers in accordance with processor power states (Cx) and sleeping states (Sx). In other words, these modified settings would cause the actual implemented states as shown above in Table 1.
• Tables 4 and 5 are illustrative delay tables. Although the present invention discloses an activation delay table 4 and PCI_RST activation delay table 5 with a plurality of specific delay values, it should be noted that other delay values can be implemented to address a particular application.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Power Sources (AREA)
• Charge And Discharge Circuits For Batteries Or The Like (AREA)
• Control Of Electric Motors In General (AREA)

Priority Applications (5)

Applications Claiming Priority (2)

Publications (1)

Family

ID=29582319

Family Applications (1)

Country Status (7)

Cited By (2)

Families Citing this family (28)

Citations (6)

Family Cites Families (3)

• 2002
  • 2002-05-28 US US10/156,706 patent/US6848057B2/en not_active Expired - Lifetime
• 2003
  • 2003-05-23 AT AT03729134T patent/ATE437393T1/de not_active IP Right Cessation
  • 2003-05-23 WO PCT/US2003/016521 patent/WO2003100589A1/en not_active Ceased
  • 2003-05-23 EP EP03729134A patent/EP1508081B1/en not_active Expired - Lifetime
  • 2003-05-23 JP JP2004507977A patent/JP4422017B2/ja not_active Expired - Lifetime
  • 2003-05-23 AU AU2003233694A patent/AU2003233694A1/en not_active Abandoned
  • 2003-05-23 DE DE60328483T patent/DE60328483D1/de not_active Expired - Lifetime

Patent Citations (6)

Also Published As

Similar Documents

Legal Events