Method and apparatus for interconnect built-in self test based system management performance tuning

[0001] 1. Technical Field

[0002] The invention relates to the field of system management. More specifically, the invention relates to failure monitoring for system management.

[0003] 2. Description of the Related Art

[0004] Certain computer systems, particularly servers and high-end workstations, include a platform management subsystem that monitors the computer system and indicates when the computer system is operating outside of a desired range. A conventional platform management subsystem includes a microcontroller that compares a sensors measurement to an associated threshold. If the sensor measurement is beyond an operating range defined by the associated threshold, then the event is logged. The logged event is then used by the platform management subsystem to determine if the computer system is operating abnormally. If the platform management subsystem determines that the computer system is operating abnormally, corrective action can be taken.

[0005] Although, platform management subsystems monitor certain operational aspects of a computer system, conventional platform management subsystems do not have access to test information related to interconnects between processor components and chipset components at operating speed.

[0006] Test information relating to interconnect operating conditions are not used beyond the manufacturing phase of a computer system (i.e., test information relating to interconnects is not used in post-production systems).

[0020] In the following description, numerous specific details are set forth to provide a thorough understanding of the invention. However, it is understood that the invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the invention.

Overview

[0021] Methods and apparatus for interconnect built-in self test based system management tuning and failure monitoring are described. A method and apparatus for interconnect built-in self-test based system management failure monitoring provides for failure detection and failure prediction based on measurements of interconnect operating conditions in a post-production system. A method and apparatus for interconnect built-in self test based system management performance tuning provides for tuning a post-production system for optimal performance based on interconnect operating condition measurements.

[0022] The results of failure monitoring based interconnect built-in self-test (IBIST) enable failure detection and failure prediction in a post-production system. Measurements of interconnect operating conditions and tracking measurements of interconnect operating conditions at operating speed of the interconnect over time enable detection of interconnect failures and/or prediction of interconnect failures (i.e., detection of degradations in operating conditions of an interconnect). The results of failure monitoring based on IBIST enable a system to respond to failures and/or potential failures.

[0023] In addition, thresholds that are indicative of a failure or degradation can be determined with IBIST result. Alternatively, thresholds that are indicative of a failure or degradation can be modified in accordance with nominal operation of an interconnect.

[0024] System management performance tuning based on IBIST improves system reliability of a post-production system. Furthermore, IBIST based system management performance tuning can be utilized for failure prediction.

IBIST Based Failure Monitoring

[0025] FIG. 1 is an exemplary block diagram of a post-production system with IBIST based failure monitoring according to one embodiment of the invention. In FIG. 1, a post-production system (e.g., a server or workstation in a live environment), includes a device A 101, a device B 109, and a platform management subsystem 111. A device may be a chipset component, a processor component, etc. The device A 101 includes IBIST logic 103 and a register(s) 105. Similarly, the device 109 includes IBIST logic 104 and a register(s) 107. IBIST logic may be firmware, software, etc. An interconnect 117 (e.g., a line, pad, pin, etc.) connects the device A 101 and the device B 109.

[0026] The platform management subsystem 111 (e.g., firmware, software, a microcontroller, etc.) includes a threshold comparison module 119 and a failure monitoring function(s) module 121.

[0027] An interface 115 couples the platform management subsystem 111 to the device A 101. An interface 113 (e.g., SMBus, I2C, etc.) couples the platform management subsystem 111 to the device B 109. The interface 113 is a bus used for inter-chip communications. In one embodiment of the invention, the bus is a 2-wire multi-master serial bus. While in one embodiment of the invention the interfaces 113 and 115 are physically separate, the interfaces 113 and 115 are a single physical interface in alternative embodiments of the invention.

[0028] The platform management subsystem 111 sends an IBIST control signal(s) to the IBIST logic 103 via the interface 115. Alternatively, or in addition, the platform management subsystem 111 sends a control signal(s) to the IBIST logic 104 via the interface 113. The IBIST logic 103 executes a built-in self-test of the interconnect 117 with respect to the device A 101. The IBIST logic 103 measures operating conditions of the interconnect 117 and stores the measurements, or results, in the register(s) 105. The platform management subsystem 111 retrieves the results from the register(s) 115. The threshold comparison module 119 analyzes the results against thresholds for failure monitoring purposes. The threshold comparison module 119 detects a failure and/or predicts a failure based on the retrieved results and threshold values in the threshold comparison module 119. In one embodiment of the invention, the threshold values are static. In another embodiment of the invention, the threshold values are configurable. If a failure is detected or predicted, then the failure monitoring function module 121 acts upon the detection or prediction. The failure monitoring function module 121 generates an alert, logs the detection or prediction, generates a status report, updates a status report, transmits a status report, and/or disables the device. Various embodiments of the invention initiate these actions differently (e.g., automatic initiation, manual initiation, remote initiation, etc.).

[0029] If a control signal(s) is sent to the IBIST logic 104 from the platform management subsystem 111, then the IBIST logic 104 measures operating conditions of the interconnect 117 and stores the measurements, or results, in the register(s) 107. These results are retrieved by the platform management subsystem 111 and analyzed and acted upon as with the results retrieved from the register(s) 105.

[0030] FIG. 2 is an exemplary diagram of a post-production system with devices having built-in threshold comparison modules according to one embodiment of the invention. In FIG. 2, a post-production system 200 includes a device A 201, a device B 209, and a platform management subsystem 211.

[0031] The device A 201 includes IBIST logic 203, a register(s) 205, and a threshold comparison module 221. The device B 209 includes IBIST logic 204, a register(s) 207, and a threshold comparison module 223. An interconnect 217 connects the device A 201 to the device B 209.

[0032] The platform management subsystem 211 includes a failure monitoring function module 225, similar to the failure monitoring function(s) module 121 of FIG. 1. The platform management subsystem 211 sends a control signal(s) (e.g., an instruction, activates a pin, etc.) to the IBIST logic 203 and/or the IBIST logic 204. Focusing on the IBIST logic 203, the IBIST logic 203 executes IBIST and measures operating conditions of the interconnect 217. The IBIST logic 203 stores the measurements in the register(s) 205. The threshold comparison module 221 retrieves these results to compare them against failure monitoring thresholds. The threshold comparison module 221 detects failure or predicts failure of the interconnect 217 based on the comparison of the IBIST results. The threshold comparison module 221 sends its threshold comparison result(s) to the platform management subsystem 211. The failure monitoring function(s) module 225 performs actions in accordance with the threshold comparison result(s) received from the threshold comparison module 221.

[0033] Although FIGS. 1 and 2 describe IBIST results as being stored in registers, in alternative embodiments of the invention IBIST results are indicated with a pin signal. Similarly, the threshold comparison results may be indicated with a pin signal.

[0034] Basing failure monitoring on IBIST results, or measurements, avoids special test hardware, software, and/or techniques typically required to access IBIST based failure information in a post-production system.

IBIST Based Failure Detection

[0035] FIG. 3 is a flowchart for IBIST execution according to one embodiment of the invention. At block 301, a device receives a request to execute IBIST. At block 303, operating condition(s) (e.g., data error rates, relative and absolute voltage, current, power, timing, voltage, jitter, etc.) of an interconnect are measured. At block 305, result(s) of measuring operating conditions are stored.

[0036] FIG. 4 is a flowchart for a platform management subsystem to analyze IBIST results according to one embodiment of the invention. At block 401, execution of IBIST is requested in accordance with a trigger (e.g., manual trigger, scheduled trigger, operating system phases, event triggers, etc.). At block 403, the interconnect operating condition measurement(s) resulting from IBIST execution are retrieved. At block 405, interconnect operating condition measurement(s) are compared against an interconnect operating condition threshold(s). At block 407, it is determined if the comparison indicates failure of the interconnect. The interconnect fails if the results of the IBIST execution go beyond the interconnect operating condition threshold(s). If the comparison indicates failure, then control flows to block 409. If the comparison does not indicate a failure, then control flows back to block 401.

[0037] At block 409, the failure detection is acted upon. From block 409, control flows back to block 401.

IBIST Based Failure Prediction

[0038] FIG. 5 is a flowchart for IBIST based failure prediction according to one embodiment of the invention. At block 501, execution of IBIST is requested in accordance with a trigger (e.g., manual trigger, scheduled trigger, operating system phases, event triggers, etc.). At block 503, the interconnect operating condition measurement(s) resulting from IBIST execution are retrieved. At block 505, interconnect operating condition measurement(s) are compared against an interconnect operating condition threshold(s). At block 507, it is determined if the comparison indicates degradation of the interconnect. The interconnect is degrading if the results of the IBIST execution indicate that the interconnect is operating in an acceptable condition, but has degraded since a last IBIST execution (e.g., since manufacturing). Failure prediction is based on IBIST results being quantitatively different than “good” or “nominal” conditions for the given interconnect, but is also quantitatively different than “bad” conditions. While in one embodiment of the invention, degradation is determined by comparing current IBIST results with a single set of previous IBIST results, in alternative embodiments of the invention degradation is determined from a trend indicated by a series of past IBIST results accumulated over time. For example, it may be determined that an interconnect is degrading is the last X results were successively worse. In another example, determination of on interconnect degrading may be based on 4 of a first 5 IBIST results being more than Z% from nominal while only 1 out of a second 5 results (which precede the first 5 in time) was more than Z% from nominal. If the comparison indicates degradation, then control flows to block 509. If the comparison does not indicate degradation, then control flows back to block 501.

[0039] At block 509, the failure prediction is acted upon. From block 509, control flows back to block 501.

[0040] FIG. 6 is an exemplary diagram of a post-production system driving test vectors according to one embodiment of the invention. The post-production system illustrated in FIG. 6 is similar to the post-production system illustrated in FIG. 1. In FIG. 6, a post-production system (e.g., a server or workstation in a live environment) includes a device A 601, a device B 609, and a platform management subsystem 611. A device may be a chipset component, a processor component, etc. The device A 601 includes IBIST logic 603 and a register(s) 605. Similarly, the device 609 includes IBIST logic 604 and a register(s) 607. IBIST logic may be firmware, software, etc. An interconnect 617 (e.g., a line, pad, pin, etc.) connects the device A 601 and the device B 609.

[0041] The platform management subsystem 611 (e.g., firmware, software, a microcontroller, etc.) includes a threshold comparison module 619 and a failure monitoring function(s) module 621.

[0042] An interface 615 couples the platform management subsystem 611 to the device A 601. An interface 613 (e.g., SMBus) couples the platform management subsystem 611 to the device B 609. While in one embodiment of the invention the interfaces 613 and 615 are physically separate, the interfaces 613 and 615 are a single physical interface in alternative embodiments of the invention.

[0043] The platform management subsystem 611 sends an IBIST control signal(s) and a test vector(s) to the IBIST logic 603 via the interface 615. Test vectors represent test data used to drive the interface during the IBIST execution. A test vector may change operating voltages, timing, current, impedance, characteristics of the interface, and/or apply such changes as a test sequence. The IBIST logic 603 executes a built-in self-test of the interconnect 617 with respect to the device A 601 under the conditions created by the test vector(s). The IBIST logic 603 measures operating conditions of the interconnect 617 and stores the measurements, or results, in the register(s) 605. The platform management subsystem 611 retrieves the results from the register(s) 605. The threshold comparison module 619 analyzes the results against thresholds for failure monitoring purposes. The threshold comparison module 619 detects a failure and/or predicts a failure based on the retrieved results and threshold values in the threshold comparison module 619. If a failure is detected or predicted, then the failure monitoring function module 621 acts upon the detection or prediction.

[0044] FIG. 7 is a flowchart for determining threshold changes for failure prediction according to one embodiment of the invention. At block 701, execution of IBIST in accordance with a trigger is requested and a test vector(s) is sent. At block 703, the interconnect operating condition measurement(s) resulting from IBIST execution is retrieved. At block 704, operating condition thresholds based on the retrieved results are determined. At block 705, the determined operating condition thresholds are compared against current thresholds. At block 707, it is determined if the comparison indicates degradation in operation of the interconnect. If the comparison indicates degradation of the operation of the interconnect, then control flows to block 709. If the comparison does not indicate degradation of the interconnect, then control flows to block 701.

[0045] At block 709, the failure prediction is acted upon. From block 709, control flows to block 701.

[0046] It is shown in FIG. 7 that tuning parameters can be used as the basis for failure prediction. A new set of tuning parameters (the test vector(s)) are selected until degradation or failure occurs in the interconnect. As the threshold changes, failures can be predicted based on current tuning parameters that caused the interconnect to reach degradation or failure against past tuning parameters.

Modifying Baselines with IBIST Results

[0047] FIG. 8 is a flowchart for determining operating conditions for baseline adjustment according to one embodiment of the invention. At block 801, a request to execute IBIST and a test vector(s) are received. At block 803, drive interconnect with the test vector(s). At block 805, the operating condition(s) of the interconnect is measured. At block 807, results of the measured operating condition(s) are stored.

[0048] FIG. 9 is a flowchart for modifying a baseline based on IBIST results according to one embodiment of the invention. At block 901, IBIST execution in accordance with a trigger is requested. At block 903, interconnect operating condition measurement(s) resulting from IBIST execution are retrieved. At block 905, an operating condition threshold(s) based on the retrieved results are determined. At block 907, it is determined if the retrieved results indicate nominal operating conditions. If the retrieved results indicate nominal operating conditions, then control flows to block 909. If the retrieved results do not indicate nominal operating conditions, then control flows to block 901.

[0049] At block 909, the baseline thresholds are modified in accordance with determined operating condition thresholds. From block 909, control flows to block 901.

[0050] Adjusting thresholds enables the thresholds to be moved closer to nominal operation, thus providing for earlier failure detection or prediction. As the tuning parameters become more extreme or further from ideal tuning parameters in order to reach nominal operation, failure or degradation becomes more eminent.

IBIST Based Performance Tuning

[0051] FIG. 10 is a flowchart for tuning operating parameters based on IBIST results according to one embodiment of the invention. At block 1001, initial test data is selected. At block 1003, initial tuning operating parameters are selected. At block 1005, selected tuning operating parameters are loaded. At block 1007, execution of IBIST is requested. At block 1009, IBIST execution results are retrieved. At block 1011, it is determined if all tuning operating parameters have been run. If all tuning operating parameters have been run, then control flows to block 1015. If all tuning operating parameters have not been run, then control flows to block 1013.

[0052] At block 1013, the next tuning operating parameters are selected. From block 1013, control flows to block 1005.

[0053] At block 1015, it is determined if loadable or selectable test data is supported. If loadable or selectable test data is supported, then control flows to block 1017. If loadable or selectable test data is not supported, then control flows to block 1019.

[0054] At block 1017, the next test data is selected. Control flows from block 1017 to block 1003.

[0055] At block 1019, the best IBIST results are determined. At block 1021, the tuning operating parameters that correspond to the best results are saved and used as actual operating parameters.

[0056] In certain embodiments of the invention, the test data and the tuning operating parameters overlap. In other embodiments of the invention, the test data and the tuning operating parameters are the same. IBIST based tuning improves system reliability by running a system in an optimized state where the nominal operating range is farther away from operating limits than the system would be without IBIST based tuning. IBIST based tuning also optimized power consumption so that components run cooler, hence increasing longevity of the components.

[0057] FIG. 11 is a flowchart for failure prediction with IBIST based tuning according to one embodiment of the invention. At block 1101, IBIST results and tuning operating parameters from earlier tuning are retrieved. At block 1103, tuning is performed. At block 1105, earlier IBIST results are compared against the retrieved results. At block 1107, it is determined if the comparison indicates degradation beyond a threshold. If the comparison indicates degradation beyond the threshold, then control flows to block 1109. If the comparison does not indicate degradation beyond the threshold, then the process ends. At block 1109, the failure prediction is acted upon.

[0058] FIG. 12 is a block diagram illustrating one embodiment of a computer system according to one embodiment of the invention. The computer system 1200 comprises a processor(s) 1201, a bus 1215, I/O devices 1203 (e.g., keyboard, mouse), and a network interface card 1207 (e.g., an Ethernet card, an ATM card, a wireless network card, etc.). The processor(s) 1201, the I/O devices 1203, and the network interface card 1207 are coupled with the bus 1215. The processor(s) 1201 represents a central processing unit of any type of architecture, such as CISC, RISC, VLIW, or hybrid architecture. Furthermore, the processor(s) 1201 could be implemented on one or more chips. The bus 1215 represents one or more buses (e.g., AGP, PCI, ISA, X-Bus, VESA, HyperTransport, etc.) and bridges. While this embodiment is described in relation to a single processor computer system, the described invention could be implemented in a multi-processor computer system.

[0059] In addition, platform management subsystem 1209 is coupled with the bus 615. The platform management subsystem 1209 has access to IBIST results for interconnects between components of the processor 1201 and chipset components of the system 1200.

[0060] The Figures above include machine-readable medium. For the purpose of this specification, the term “machine-readable medium” shall be taken to include any mechanism that provides (i.e., stores and/or transmits) information in a form readable by a machine (e.g., a computer). A set of instructions (i.e., software) embodying any one, or all, of the methodologies described herein is stored on the machine-readable medium. Software can reside, completely or at least partially, within this machine-readable medium and/or within the processor and/or ASICs. For example, a machine-readable medium includes read only memory (“ROM”), random access memory (“RAM”) (e.g., DDR SDRAM, EDO DRAM, SDRAM, BEDO DRAM, etc.) magnetic disk storage media, optical storage media, flash memory devices, electrical, optical, acoustical, or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.), etc.

[0061] In addition to other devices, one or more of a video card 1205 may optionally be coupled to the bus 1215. The video card 1205 represents one or more devices for digitizing images, capturing images, capturing video, transmitting video, etc.

[0062] While the invention has been described in terms of several embodiments, those skilled in the art will recognize that the invention is not limited to the embodiments described. The method and apparatus of the invention may be practiced with modification and alteration within the spirit and scope of the appended claims. The description is thus to be regarded as illustrative instead of limiting on the invention.