US20090217070A1 - Dynamic Bus Parking - Google Patents

Systems and methods of power management provide for issuing a power saving message from a processor toward a controller and using the controller to conduct a power saving activity in response to the power saving message. In one embodiment, the power saving message is issued by de-asserting a bus arbitration signal and the power saving activity can include disabling one or more input buffers of the controller.

CROSS REFERENCE TO RELATED APPLICATIONS

• The present application is related to U.S. patent application Ser. No. 10/317,798, filed on Dec. 11, 2002; U.S. patent application Ser. No. 10/317,776, filed on Dec. 11, 2002; U.S. patent application Ser. No. 10/931,565, filed on Aug. 31, 2004; U.S. patent application Ser. No. 10/442,595, filed on May 21, 2003; and U.S. Pat. No. 6,842,035, issued on Jan. 11, 2005.

BACKGROUND

• 1. Technical Field

• Certain embodiments of the present invention generally relate to power management. In particular, some embodiments relate to platform level power management.

• 2. Discussion

• As the components of modern day computing systems continue to grow in functionality and computing form factors continue to decrease in size, computer designers and manufacturers are often faced with significant challenges related to increased power consumption. As a result, a number of techniques have been developed to reduce power consumption. For example, some approaches involve powering down system components when their functionality is not needed. While these solutions can be suitable under certain circumstances, there remains considerable room for improvement.

BRIEF DESCRIPTION OF THE DRAWINGS

• The various advantages of the embodiments of the present invention will become apparent to one skilled in the art by reading the following specification and appended claims, and by referencing the following drawings, in which:

• FIG. 1

  is a block diagram of an example of an apparatus according to one embodiment;

• FIGS. 2A and 2B

  are timing diagrams of examples of input buffer disabling schemes according to first and second embodiments, respectively;

• FIG. 3

  is a flowchart of an example of a method of power management according to one embodiment;

• FIG. 4

  is a block diagram of an example of a system according to one embodiment.

DETAILED DESCRIPTION

• In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the present invention. It will be evident, however, to one skilled in the art that the embodiments of the present invention may be practiced without these specific details. In other instances, specific apparatus structures and methods have not been described so as not to obscure the embodiments of the present invention. The following description and drawings are illustrative of the embodiments of the invention and are not to be construed as limiting the embodiments of the invention.

• Some portions of the detailed description, which follow, may be presented in terms of algorithms and symbolic representations of operations on data bits or binary digital signals within a computer memory. These algorithmic descriptions and representations may be the techniques used by those skilled in the data processing arts to convey the substance of their work to others skilled in the art. For example, certain logic described herein may be implemented using hardware techniques such as complementary metal oxide semiconductor (CMOS) technology or transistor-transistor logic (TTL), controller firmware, microcode, software techniques, and any combination thereof. The components described herein may also be incorporated into one or more integrated circuit (IC) packages (i.e., chips) which are fabricated on a die cut from a wafer.

• Any use of the terms “first”, “second”, etc. does not necessarily infer a chronological relationship, and is used to facilitate discussion only. Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification, discussions utilizing terms such as “processing,” “computing,” “calculating,” “determining,” or the like, refer to the action and/or processes of a computer or computing system, or similar electronic computing device, that manipulate and/or transform data represented as physical, such as electronic, quantities within the computing system's registers and/or memories into other data similarly represented as physical quantities within the computing system's memories, registers or other such information storage, transmission or display devices. Furthermore, terms such as “coupled” or “coupling” can be used to refer to any connection, direct or indirect, between the components in question and can involve a mechanical, electrical, optical, electromagnetic, or other type of relationship.

• As used herein, the term “transaction” designates a bus activity that is related to a single bus access request. A transaction may include several phases, where each phase is associated with a specific set of bus signals to communicate a particular type of information. For one embodiment, exemplary phases may include, for example, an arbitration phase, a request phase, a snoop phase, a response phase and/or a data phase.

• In the request phase, the requesting agent can drive request control and address information on the bus. During a subsequent snoop phase, it may be determined, whether sought after data is stored locally and/or whether the transaction is likely to be completed in order with respect to previously issued transactions. In a response phase, a response agent can report to the requesting agent information indicating whether the requested transaction has succeeded or failed. If the requested transaction includes data transfer, a data phase, also referred to as a data transfer phase, may be initiated in response to the assertion of a data ready signal.

• FIG. 1

  shows an

  apparatus

  10 having a

  controller

  12 and a

  processor

  18. The

  processor

  18 and the

  controller

  12 may communicate with one another over a

  bus

  22, where in one example the

  bus

  22 may be a pipelined front side bus (FSB) that includes address, data and control portions. The address, data and control portions may also be referred to as address, data and control buses. In another example, the

  bus

  22 may be part of a point-to-point interconnection fabric that enables direct communication among multiple components of a computing system. The illustrated

  controller

  12, which may be part of a graphic model and memory controller hub (GMCH), commonly used on computing system chipsets, has a power saving

  message line input

  14 and

  power management logic

  21. The

  controller

  12 may also include one or

  more input buffers

  16 coupled to the

  bus

  22 and the

  power management logic

  21,

  local logic

  23 coupled to the

  power management logic

  21, and

  external logic

  25 coupled to the

  power management logic

  21.

• The illustrated

  input buffer

  16 has a plurality of

  sense amplifiers

  24 that may consume a significant amount of power when enabled for receiving data. The illustrated

  local logic

  23 may include internal components such as functional blocks for performing the various operations provided by the

  controller

  12. For example, the

  local logic

  23 could conduct memory or input/output (10) management operations. The illustrated

  external logic

  25 could include external components such as one or more memory device (e.g., system memory) functional blocks, where the

  external logic

  25 may be managed by the

  controller

  12. The illustrated

  local logic

  23 and

  external logic

  25 may also consume a significant amount of power when enabled for operation.

• The

  processor

  18 can have

  power state logic

  27 and

  bus logic

  20, which may also be referred to as a bus agent, capable of issuing a power saving message to the

  controller

  12. The illustrated

  power management logic

  21 of the

  controller

  12 is able to conduct a power saving activity in response to the power saving message. The power saving message may be conveyed in a number of different ways. For example, in the illustrated example, the processor uses a bus arbitration line to communicate the power saving message to the

  controller

  12.

• In particular, the illustrated

  bus logic

  20 asserts a bus arbitration signal toward the

  line input

  14 whenever the processor needs to communicate with the

  controller

  12 over the

  bus

  22. In the illustrated example, the bus arbitration signal is identified as the “BREQ#” signal. For the purposes of this discussion, a “#” at the end of a signal name indicates that the associated signal is an active low signal (i.e., considered to be asserted when it drives a logic low level on the external bus). It will be appreciated that active high signals may be used instead with corresponding changes in associated circuitry to provide similar functionality. Further, for one embodiment, one or more of the signals associated with the

  bus

  22 are low voltage swing signals that have a voltage swing smaller than full swing. It can also be understood that the bus arbitration signal may be an encoded message rather than the physical signal BREQ#.

• The

  bus logic

  20 is also able to de-assert the bus arbitration signal in order to instruct the

  controller

  12 to conduct the power saving activity. The power saving activity may involve disabling one or more internal components of the

  controller

  12 and/or disabling one or more external components that are managed by the

  controller

  12. For example, the disabled internal components could include the

  sense amplifiers

  24 of the

  input buffer

  16, the

  local logic

  23, and so on. Similarly, the disabled external components could include the

  external logic

  25, where conducting the power saving activity may involve placing a system dynamic random access memory (DRAM) into a power down state (e.g., self refresh) if the

  controller

  12 is a memory controller. The

  power management logic

  21 of the

  controller

  12 can therefore detect the de-assertion of the bus arbitration signal and conduct various power saving activities in response to detecting the de-assertion.

• In the case of the disabling of the

  input buffer

  16, the

  bus

  22 can be said to be dynamically “parked” from the perspective of the

  controller

  12. Accordingly, by enabling the

  processor

  18 to selectively conduct power saving activities such as disabling the

  input buffer

  16 of the

  controller

  12, the

  bus logic

  20 provides substantial power savings over conventional approaches. These power savings can lead to greater battery life in mobile platforms as well as reduced temperatures. In fact, extending the power features of the

  bus

  22 to the

  controller

  12 side of the

  bus

  22, represents a significant advantage over conventional power management architectures.

• Turning now to

  FIG. 2A

  , an example of the signaling for one

  power management scheme

  26 is shown in greater detail. In the illustrated example, a

  bus clock signal

  28 is shown in relation to a bus arbitration signal (BREQ#) 30, a bus priority signal (BPRI#) 32, a power status indicator signal (PSI#) 34, an address strobe common clock signal (ADS#) 36, an address/request signal (Addr/Req.) 38 and an address synchronous strobe signal (ADSTB#) 40. A data ready signal (DRDY#) 41 and

  data bus signal

  43 are also shown. In the illustrated example, the

  bus arbitration signal

  30 is asserted by the processor bus logic during the T0 clock cycle to gain bus ownership in order to communicate with the controller. The illustrated common clock and address strobe signals 36, 40, facilitate the transfer of information via the address/request signal 38 (i.e., “A” and “B”) during the T2-T4 clock cycles. In particular, the

  common clock signal

  36 is used to indicate that a new transaction is to be issued to the bus and the

  asynchronous strobe signal

  40 is used to sample the double pump address lines.

• The illustrated

  bus arbitration signal

  30 is de-asserted during the Tn clock cycle. The controller input buffers, which were disabled in the T0 clock cycle, can be disabled upon completion of the last burst data transfer associated with the

  DRDY# assertion

  45. In particular, although de-assertion of the

  bus arbitration signal

  30 indicates that the processor has completed an issue request, all data transfers related to this request should complete before the input buffers are disabled. Thus, the internal buffers of the controller can become disabled in the illustrated Tn+2 clock cycle. The result can be a substantial reduction in power consumption within the controller.

• It should be noted each time the

  bus arbitration signal

  30 is re-asserted, there may be a minimal impact on performance because a re-arbitration may be necessary before the next transaction can take place on the bus. For example, re-arbitration could impose two clocks of additional latency (e.g., T0 and T1 clock cycles in the example shown) on the system. Frequent transitions into and out of the processor-initiated power saving state could therefore cause an undesirable minimum reduction in performance. Accordingly, an

  idle counter

  42 can be used to ensure that the bus has been idle for a sufficient amount of time (i.e., T6 and T7 clock cycles in the example shown) before de-asserting the

  bus arbitration signal

  30. It should also be noted that the idle counter value can programmed to any value (i.e., zero and up) depending upon the circumstances. In this regard, the processor bus logic may need to retrieve the counter value from a programmable memory location such as the basic input/output system (BIOS) erasable programmable read only memory (EPROM) and compare the number of idle clock cycles to the counter value in determining whether to de-assert the

  bus arbitration signal

  30.

• The decision whether to de-assert the

  bus arbitration signal

  30 can also be made based on the operating frequency of the processor. In this regard, the processor could be capable of selectively reducing its frequency/voltage during periods of relative inactivity or to otherwise save power. Thus, de-assertion of the

  bus arbitration signal

  30 could be limited to time periods when the operating frequency of the processor is below some frequency threshold.

• In one example, a processor can enter a low frequency mode (LFM) in order to achieve greater battery life. If the processor is able to enter such a low frequency mode, it may be desirable to limit the use of the bus arbitration de-assertion to the LFM periods in order to “hide” the potential performance penalty associated with the de-assertion. Simply put, the de-assertion penalty may be negligible in comparison to the performance penalty associated with the LFM. Thus, in the illustrated example, the processor bus logic ensures that the

  LFM signal

  34 is asserted before proceeding with the de-assertion of the

  bus arbitration signal

  30. The frequency at which the power saving activity is activated may be programmable. For example, it is possible to store the value 1.3 GHz, where each time the processor enters a frequency equal to or lower than 1.3 GHz, the power saving message will be asserted. Alternatively, the power saving message could be asserted each-time the performance state (e.g., P state) of the processor falls below a predetermined level. The same applies to a plurality of cores/processors where the combined state is evaluated.

• Alternatively, the state of the

  LFM signal

  34 could be ignored altogether when deciding whether to de-assert the

  bus arbitration signal

  30. One circumstance in which such an approach may be acceptable could be in the case of a very small computing platform (e.g., handheld personal digital assistant) where battery life may always take priority over performance.

• Although not shown, the processor bus logic could further base the decision whether to de-assert the

  bus arbitration signal

  30 on the bus ratio (i.e., the ratio of the processor operating frequency to the bus operating frequency). For example, the processor bus logic could confirm that the bus ratio is below a particular threshold to ensure that the de-assertion related performance loss is not visible. Such a technique could be employed in addition to or instead of the raw frequency check provided by

  LFM signal

  34. If the

  LFM signal

  34 is not used, the bus ratio approach could facilitate acceptable operation even when the processor is in the high frequency mode.

• It should also be noted that the

  bus power signal

  32, which may travel from the controller to the processor, can also be de-asserted by the controller in order to effectively disable the input buffers of the processor and achieve even greater power savings.

• FIG. 2B

  shows an example of a

  power management scheme

  44 in which the controller supports more than one processor. In this example, a first processor is associated with a first bus arbitration signal (BREQ[0]#) 46 and a second processor is associated with a second bus arbitration signal (BREQ[1]#) 48. The two bus arbitration signals 46, 48 can be ORed together so that the input buffer of the controller is enabled whenever either of the processors is asserting the signal. Thus, in the illustrated example, the controller input buffer is enabled until the Tn+2 clock cycle, where both bus arbitration signals 46, 48 are de-asserted. A multiprocessor bus arbitration protocol can be used to manage the assertion/de-assertion of the

  signals

  46, 48. It can also be seen that in the illustrated example, a counter value of three clock cycles is used so that the last processor to attempt to de-assert its respective bus arbitration signal (i.e., the second processor in the example shown) is forced to wait for the T6 through Tn clock cycles to complete before disabling the controller input buffer via

  bus arbitration signal

  48.

• Turning now to

  FIG. 3

  , a

  method

  50 of power management is shown. The

  method

  50 may be implemented as processor bus logic using hardware techniques such as complementary metal oxide semiconductor (CMOS) technology or transistor-transistor logic (TTL), controller firmware, microcode, software techniques, and any combination thereof. In the illustrated example, processing

  block

  52 provides for asserting a bus arbitration signal from a processor toward a controller having a bus arbitration line input and an input buffer. If it is determined at

  block

  54 that the operating frequency of the processor is at or below a frequency threshold (e.g., at or below a particular Advanced Configuration and Power Interface/ACPI Specification, Rev. 3.0, Sep. 2, 2004, Px state; in low frequency mode, etc.), block 56 provides for determining whether a bus disposed between the processor and the controller has been idle for a certain amount of time. As already discussed, the determination at

  block

  56 may involve comparing the number of idle clock cycles to a counter value, which may be retrieved from a programmable memory location. If the bus is sufficiently idle, the bus arbitration signal can be de-asserted at

  block

  58 in order to instruct the controller to disable its input buffer.

• If it is determined at

  block

  54 that the operating frequency of the processor is not at or below the frequency threshold, block 60 provides for determining whether the bus ratio is below a certain threshold. For example, it could be determined that if the bus ratio is less than 2:1, the relative processor performance is such that the additional performance loss associated with the de-assertion may be negligible. Thus, if

  block

  60 determines that the bus ratio is below the relevant threshold, a check of the bus idleness can still be conducted at

  block

  56. Otherwise, the process returns to block 52 for re-assertion of the bus arbitration signal.

• FIG. 4

  shows a

  computing system

  64, which could be part of a server, desktop personal computer (PC), notebook PC, personal digital assistant (PDA), wireless “smart” phone, and so on. The illustrated

  system

  64 has a

  microprocessor

  18, which may have one or more processor cores (not shown), where each core may be fully functional with instruction fetch units, instruction decoders, level one (L1) cache, execution units, and so on. The

  microprocessor

  18 may also include

  bus logic

  20 as already discussed. The

  microprocessor

  18 can communicate with a graphic model and memory controller hub (GMCH) 66, also known as a Northbridge, via a

  front side bus

  22. As already noted, the

  front side bus

  22 could alternatively be replaced by a point-to-point fabric that interconnects each of the components in the

  system

  64. The

  GMCH

  66, which may include a

  controller

  12, can communicate with system random access memory (RAM) 68 via a

  memory bus

  70. In one embodiment, the

  RAM

  68 includes dynamic random access memory (DRAM) modules. The modules of the

  RAM

  68 may be incorporated in to a single inline memory module (SIMM), dual inline memory module (DIMM), small outline DIMM (SODIMM), and so on. The

  GMCH

  66 may also include one or more graphics devices (not shown).

• The illustrated

  GMCH

  66 communicates with an I/O controller hub (ICH) 72, also known as a Southbridge, via a

  hub bus

  74. The

  GMCH

  66 and the

  ICH

  72 are sometimes referred to as a

  chipset

  86. The

  microprocessor

  18 may also be operatively connected to a

  network

  76 via a

  network port

  78 through the

  ICH

  72. The

  ICH

  72 may also be coupled to

  storage

  80, which may include a read only memory (ROM) 122,

  flash memory

  84, etc. In one embodiment, the

  bus logic

  20 is configured to selectively assert a bus arbitration signal toward the

  controller

  12 in order to reduce the power consumption of the

  chipset

  86.

• As already noted, various embodiments of the disclosed subject matter may be implemented in hardware, firmware, software, or combination thereof, and may be described by reference to or in conjunction with program code, such as instructions, functions, procedures, data structures, logic, application programs, design representations or formats for simulation, emulation, and fabrication of a design, which when accessed by a machine results in the machine performing tasks, defining abstract data types or low-level hardware contexts, or producing a result.

• For simulations, program code may represent hardware using a hardware description language or another functional description language which essentially provides a model of how designed hardware is expected to perform. Program code may be assembly or machine language, or data that may be compiled and/or interpreted. Furthermore, it is common in the art to speak of software, in one form or another as taking an action or causing a result. Such expressions are merely a shorthand way of stating execution of program code by a processing system which causes a processor to perform an action or produce a result.

• Program code may be stored in, for example, volatile and/or non-volatile memory, such as storage devices and/or an associated machine readable or machine accessible medium including solid-state memory, hard-drives, floppy-disks, optical storage, tapes, flash memory, memory sticks, digital video disks, digital versatile discs (DVDs), etc., as well as more exotic mediums such as machine-accessible biological state preserving storage. A machine readable medium may include any mechanism for storing, transmitting, or receiving information in a form readable by a machine, and the medium may include a tangible medium through which electrical, optical, acoustical or other form of propagated signals or carrier wave encoding the program code may pass, such as antennas, optical fibers, communications interfaces, etc. Program code may be transmitted in the form of packets, serial data, parallel data, propagated signals, etc., and may be used in a compressed or encrypted format.

• Program code may be implemented in programs executing on programmable machines such as mobile or stationary computers, personal digital assistants, set top boxes, cellular telephones and pagers, and other electronic devices, each including a processor, volatile and/or non-volatile memory readable by the processor, at least one input device and/or one or more output devices. Program code may be applied to the data entered using the input device to perform the described embodiments and to generate output information. The output information may be applied to one or more output devices. One of ordinary skill in the art may appreciate that embodiments of the disclosed subject matter can be practiced with various computer system configurations, including multiprocessor or multiple-core processor systems, minicomputers, mainframe computers, as well as pervasive or miniature computers or processors that may be embedded into virtually any device. Embodiments of the disclosed subject matter can also be practiced in distributed computing environments where tasks may be performed by remote processing devices that are linked through a communications network.

• Although operations may be described as a sequential process, some of the operations may in fact be performed in parallel, concurrently, and/or in a distributed environment, and with program code stored locally and/or remotely for access by single or multi-processor machines. In addition, in some embodiments the order of operations may be rearranged without departing from the spirit of the disclosed subject matter. Program code may be used by or in conjunction with embedded controllers.

• Those skilled in the at can appreciate from the foregoing description that the broad techniques of the embodiments of the present invention can be implemented in a variety of forms. Therefore, while the embodiments of this invention have been described in connection with particular examples thereof, the true scope of the embodiments of the invention should not be so limited since other modifications will become apparent to the skilled practitioner upon a study of the drawings, specification, and following claims.