The disclosures herein relate generally to processors, and more particularly, to injecting errors in processors for testing purposes.
The complexity of processor design continues to increase year after year at a dramatic pace. Error testing and hardware verification likewise continue to gain in importance for these increasingly complex structures. One approach to error testing is the familiar Joint Test Action Group (JTAG) interface which many processors and other integrated circuits employ. The JTAG interface uses boundary scan techniques to test integrated circuits by incorporating a shift register into each chip under test. This enables the shifting of input signals in and the shifting of output signals out of the chip via 4 I/O pins, namely input data, output data, clock and mode control. The JTAG approach obviated the former requirement for expensive, customized bed-of-nails type probe testing arrays.
In a typical processor test scenario, a debugger program or tool communicates with the JTAG interface on an integrated circuit. The debugger program instructs the JTAG interface with test input information regarding the tests conducted in the integrated circuit. When the integrated circuit completes the prescribed tests, the debugger program collects the resultant test output information from the JTAG interface on the integrated circuit.
Integrated circuits may include error injection circuitry that intentionally introduces errors into the various functional blocks or functional units that form an integrated circuit. Integrated circuits may also include fault isolation registers (FIRs) that collect information regarding errors that occur in the functional blocks of the integrated circuit. As the size and complexity of integrated circuits increase, management of error injection and collect of error information becomes increasingly difficult. Moreover, different integrated circuits often employ very different approaches to error injection, error collection and interpretation of error information. This tends to slow the integrated circuit design process.
What is needed is a method and apparatus that performs error injection in integrated circuits and that addresses the problems described above.
Accordingly, in one embodiment, a method is disclosed for error handling in a processor system including a plurality of local functional units. The method includes storing error information locally in respective local fault isolation registers coupled to the local functional units. The method also includes generating, by a test instruction source, test instructions relating to errors associated with the local functional units. The method further includes providing a global fault isolation layer between the test instruction source and the local fault isolation registers. In this manner, a user of a test instruction source, such as a debugger, need not have an intricate knowledge of the local error handling of the local functional units.
In another embodiment, a processor system is disclosed including a plurality of local functional units that store error information locally in respective local fault isolation registers coupled to the local functional units. The processor system also includes a test instruction source that provides test instructions relating to errors associated with the functional units. The processor system further includes a global fault isolation layer coupling the test instruction source to the local fault isolation registers. Again, in this manner, a user of a test instruction source, such as a debugger, need not have an intricate knowledge of the local error handling of the local functional units.
The appended drawings illustrate only exemplary embodiments of the invention and therefore do not limit its scope because the inventive concepts lend themselves to other equally effective embodiments.
The disclosed system processor system includes a hierarchical error detection, error injection and error handling capability. The term RAS (reliability, availability, serviceability) describes error handling in general. In one embodiment, the disclosed processor system employs hardware at a top level of a hierarchically organized RAS (error detection) environment within the system to inject errors at the top level.
The disclosed processor system employs a hierarchical RAS structure for error detection and failure analysis. In one embodiment of the disclosed processor system, several functional blocks from existing standalone chips integrate together on a common chip to form a so-called “system on a chip” or SOC. Examples of such functional blocks include structures such as processors, co-processors, L2 cache memories, bus interface units and other functional units. Each of these formerly stand-alone chips typically has its own different error handling mechanisms. The disclosed processor system integrates these functional blocks with their different error handling mechanisms on a common IC to form the SOC. The processor system employs a hierarchical approach to error detection and failure analysis. In one embodiment, the processor system may employ existing hardware and software-assisted recovery mechanisms from the respective functional blocks. Different error handling mechanisms associated with such different functional blocks connect to an upper hierarchy level of error detection and failure analysis within the processor system. The error handling hierarchy of the processor system includes an upper or top hierarchy level that may communicate with a standard test interface such as the JTAG interface. In this manner, the disclosed processor may accommodate different error handling and recovery mechanisms in a common SOC.
While the disclosed processor can accommodate the different error handling and recovery mechanisms of different respective functional units in a single SOC, this hierarchical approach does increase the test complexity of the resultant SOC with respect to chip verification and “bring-up”. The term “verification” means verifying hardware, such as the disclosed processor, in a simulation environment before the hardware really exists, i.e. before the hardware is actually manufactured. “Bring-up” is the test of the real, manufactured and assembled system hardware including, for example, different integrated circuit chips, memories and boards in interaction with written and developed systems' software and firmware. In one embodiment, the disclosed processor's testing mechanisms include effectively degating lower hierarchical levels and emulation of error injection at the top level of the error handling hierarchy. The top level of the error handling hierarchy couples to a JTAG interface that communicates with a debugger software application. This configuration facilitates integrated circuit chip verification and bring-up without a top-down knowledge of the entire system by a person conducting the test. Moreover, testing may commence even though some functional units are not complete or are otherwise unavailable during the design process. The disclosed processor includes software controlled hardware that provides error injection at the top level of the error handling hierarchy and effectively breaks off the top level of the hierarchy from lower levels of the hierarchy for testing purposes. In this manner, a person conducting a test of the disclosed processor need not understand error injection logic at all of the functional units at lower levels of the hierarchy.
As described above, when each functional unit includes its own unique error detection mechanism in a system on a chip (SOC), difficulties can arise in detecting errors from these multiple different sources which may also be called local error handlers. To address this problem a local error handler includes local error injection circuits for the respective functional units of the SOC. The local error handler stores error information in local fault isolation registers (FIRs) for the respective functional units. To enable the local error handler to effectively communicate with a hardware test interface such as, for example the JTAG interface, the disclosed system on a chip (SOC) includes a global error handler that interfaces the local error handler to a hardware test interface. The term “local error handler” corresponds to local fault handler. Similarly, the term “global error handler” corresponds to global fault handler.
Local fault handler 105B includes a processor unit (PPU) core fault isolation register (FIR) 120A that couples to a processor unit (PPU) 120B which is yet another functional unit of system 100, namely a main processor of the system. Local fault handler 105B further includes a local I/O FIR 121A, a local memory interface unit (MIU) FIR 122A, a local L2 cache FIR 123A and a local bus interface (B IF) FIR 124A that respectively couple to an I/O interface 121B, a memory interface unit 122B, an L2 cache memory 123B, and a bus interface 124B, and further respectively couple to a local I/O interface specific error injection circuit 121C, a local memory interface unit specific error injection circuit 122C, a local L2 cache interface error injection circuit 123C and a local bus interface error injection circuit 124C, as shown. D cache error bit receiver 110A, I cache error bit receiver 112A and ALU error bit receiver 114A couple to processor unit core FIR 120A as shown. Processor unit core FIR 120A couples to a processor core (PPU) 120B which is one of the functional units of system 100.
In
In the particular embodiment shown in
SPE-0 is representative of the SPEs employed by system 100. SPE-0 includes a synergistic processor unit, SPU-0, namely a processor, that couples to a local store, LS-0, and a memory flow control unit, MFC-0. In one embodiment, each SPE includes fault isolation registers, FIRs, that store and lock local error conditions. SPE-0 includes a local store fault isolation register, LS-0 FIR, coupled to local store LS-0. SPE-0 further includes a memory flow control fault isolation register, MFC-0 FIR, coupled to memory flow control, MFC-0. SPE-0 also includes an error specific error injection circuit, SPE-0 ERROR SPECIFIC ERROR INJECT, that couples to local store fault isolation register, LS-0, to inject errors therein. SPE-2 through SPE-5 exhibit substantially the same topology as SPE-0 described above. SPE-0, SPE-1, . . . SPE-5 each include correctable error outputs (C) and uncorrectable error outputs (UC) that couple to correctable error bus 125 and uncorrectable error bus 127, respectively.
A global fault handler 140 couples to local fault handler section 105B as shown to receive correctable error information, uncorrectable error information and machine check information therefrom. Global fault handler 140 provides a common or central location to collect local error information from the local FIRs 121A, 122A, 123A and 124A and also collect local error bit information from local error bit receivers 110A, 112A and 114A. Moreover, global fault handler 140 provides a layer of isolation between local fault handler 105 and debugger software 170 discussed below. Global fault handler 140 includes a global FIR section 141. Global FIR section 141 includes a global machine check FIR 142, a global correctable error FIR 143 and a global uncorrectable error FIR 144. Global machine check FIR 142 captures and stores machine check information received from machine check bus 129. Global correctable error FIR 143 couples to a multiplexer 145 that includes an input that couples to correctable error bus 125 and another input that couples to a correctable error injection port 146. In this manner, global fault handler 140 selectably supplies either an actual correctable error from local fault handler 105B or an injected correctable error from port 146 to the correctable error FIR 143.
Global uncorrectable error FIR 144 couples to a multiplexer 147 that includes an input that couples to uncorrectable error bus 127 and another input that couples to an uncorrectable error injection port 148. In this manner, global fault handler 140 selectably supplies either an uncorrectable error from local fault handler 105B or instead an injected uncorrectable error from port 148 to the uncorrectable error FIR 144. An external uncorrectable error pin 149 provides another port for the purpose of reporting system-wide uncorrectable errors to the SOC. In one embodiment, a system controller may apply a signal to pin 149 to stop any clocking signals in SOC 100 in case of a system emergency, such as for example a failing memory device detected by a memory controller.
Global fault handler 140 also includes global logic 150 that couples to global machine check FIR 142, global correctable error FIR 143 and global uncorrectable error FIR 144. Global logic 150 includes mask register functions and logic functions. Using these mask register functions, global logic 150 can mask any error reported from the local FIRs. Such masking may be helpful for debug and analysis purposes. Each local FIR, such as I/O IF FIR 121A and MIU FIR 122A, for example, includes an error counter (not shown). These counters in the local FIRs count every correctable error associated with the unit which couples to the FIR. Global fault handler 140 includes global logic 150 which controls this counting activity. This global logic 150 makes possible system performance measurements regarding correctable error occurrences and related error recovery. Global fault handler 140 may be set to different error modes as described below in more detail.
A JTAG interface 160 couples to global fault handler 140. The JTAG interface 160 includes control logic that couples JTAG interface 160 to global logic 150. Global logic 150 reports all errors to JTAG interface 160, coupled thereto. JTAG interface 160 includes a JTAG status register 162 that couples to global logic 150. In one embodiment, JTAG interface 160 may control global fault handler 140. A debugger 170 couples to JTAG interface 160 to instruct system 100 with respect to which error tests to be conducted, for example which errors to be injected by the error injection circuits thereof. JTAG status register 162 includes a plurality of bits wherein each bit corresponds to a different error occurrence, for example, one bit for machine check, one bit for correctable error and another bit for uncorrectable error. In one embodiment, JTAG status register 162 includes maskable bits. Debugger 170 includes an external attention pin 172 designated EXT_ATTENTION_PIN that represents the summation of all bits, namely the logic OR of all bits, of JTAG status register 162.
Returning now to the example of
To configure FIR circuitry 200 to generate a checkstop error or unrecoverable error at output UC, system 100 programs checkstop enable register 220 with a logic high and error mask register 222 with a logic low. The remaining AND gate 230 input not coupled to registers 220 or 222 couples to the output of local FIR 204. The output of AND gate 230 couples via a two input OR gate 250 to output UC. The input of OR gate 250 not coupled to AND gate 230 receives other information such as any checkstop bits in local FIR 204. Similarly, system 100 may configure configuration registers 220, 222 and 224 to supply recoverable errors to output C. The system logic 202 provides an error without injection, namely a naturally occurring error. Initially, system 100 does not know what kind of error it is. Error mask register 222 and machine check enable register 224 help system 100 determine the type of error. Error mask register 222 determine the general system participation is error handling. For debug purposes, error mask register 222 can be enabled and disabled. Checkstop enable register 220 determines system 100 treats a particular error as an uncorrectable error or a correctable error. In one embodiment, the default value for checkstop enable register 220 is a “correctable” error. Machine check enable register 224 decides if a particular error participates as a “machine check” type of error or “correctable error”. A “machine check” type of error is a type of error for which system software handles the error and decides if the error is correctable by a recovery or the system needs to be stopped. System 100 may also configure configuration registers 220, 222 and 224 to supply machine checks at output M. System 100 may also configure configuration registers 220, 222 and 224 to supply the error contents of local FIR 204 to output C. As seen in
JTAG controller 305 and system software 300 couple to respective inputs of a selector 310 so that each may access a control register 315 that couples to the output of selector 310 as shown. Control register 315 includes a selection field section 315A and a control field section 315B. The register bits of selection field section 315A of
When system access software 300 or debugger software 170 so addresses a functional unit, the system access software or debugger software can also specify the type of error that system 100 should employ for that functional unit by specifying an appropriate bit in control field 315B. In this manner, system 100 controls the error type or mode currently employed. As seen in
Output decoder 325 couples to global FIR input multiplexer 330 via the following lines which specify either correctable or uncorrectable errors at designated respective functional units: PPU correctable error, I/O IF correctable error, MIU correctable error, L2 correctable error, B IF correctable error, SPE correctable error(0), . . . SPE correctable error (5).
By way of example, to inject a correctable error in the functional unit referred to as I/O IF 123B, debugger software 170 activates selector 310 to connect the debugger to control register 315. Debugger software 170 then sets bit 1 of the selection field 315A to 1 and the UE bit of the control field 315B to 0. Control and decoder logic 320 interprets the control field and instructs output decoder 325 that debugger software 170 specified a correctable error. Decoder 325 interprets the bits of selection field 315A to determine that the debugger software specified the injection of an error in the I/O IF functional block 121B. Global FIR input multiplexer 330 then instructs the global correctable error FIR 143 with respect to the particular specified error. Global correctable error FIR 143 receives and stores the specified injected correctable error specified for the I/O IF functional block 121B. FIRs 143 and 144 immediately store any errors presented thereto. Global correctable error FIR 143 and global uncorrectable error FIR 144 each include a respective bit dedicated to each functional unit. Every correctable error, uncorrectable error or machine check error have one bit per functional unit allocated at the global level, namely at machine check FIR 142, correctable error FIR 143 and uncorrectable error FIR 144. As seen in
The foregoing discloses a processor that injects errors at a local and global level to provide error testing for multiple different functional units.
Modifications and alternative embodiments of this invention will be apparent to those skilled in the art in view of this description of the invention. Accordingly, this description teaches those skilled in the art the manner of carrying out the invention and is intended to be construed as illustrative only. The forms of the invention shown and described constitute the present embodiments. Persons skilled in the art may make various changes in the shape, size and arrangement of parts. For example, persons skilled in the art may substitute equivalent elements for the elements illustrated and described here. Moreover, persons skilled in the art after having the benefit of this description of the invention may use certain features of the invention independently of the use of other features, without departing from the scope of the invention.