|Publication number||US7331043 B2|
|Application number||US 10/180,580|
|Publication date||Feb 12, 2008|
|Filing date||Jun 26, 2002|
|Priority date||Jun 26, 2001|
|Also published as||US20020199175|
|Publication number||10180580, 180580, US 7331043 B2, US 7331043B2, US-B2-7331043, US7331043 B2, US7331043B2|
|Inventors||Ashley N. Saulsbury|
|Original Assignee||Sun Microsystems, Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (13), Non-Patent Citations (2), Referenced by (15), Classifications (13), Legal Events (5)|
|External Links: USPTO, USPTO Assignment, Espacenet|
1. Field of the Invention
The invention relates to fault detection and/or tolerance, and in particular, to techniques for detecting and/or mitigating the effects of transient soft errors using otherwise duplicative instructions in an instruction stream.
2. Description of the Related Art
It has long been recognized that electronic circuits are vulnerable to a variety of sources of transient “soft errors.” In contrast to hard errors caused by physical defects in a device or circuit, the term “soft error” generally refers to transient state errors rather than persistent errors resulting from device or circuit defects or damage. As a general matter, electronic circuits function by identifying small packets of charge as elemental bits of information. Accordingly, any perturbation of these small packets of charge may change the stored information. Sources of perturbation include electromagnetic energy, noisy power supplies and radiation. As device sizes become smaller, susceptibility to soft errors generally increases. In a typical semiconductor integrated circuit, soft errors may trace to environmental factors, externally- or internally-driven power supply perturbations, design factors including operation of an otherwise stable design outside its design envelope, etc.
One of the important sources of soft errors is the ionizing radiation associated with radioactive decay. The semiconductor industry has, over the years, struggled with the effect of trace levels of radioactive isotopes introduced by materials, packaging and manufacturing techniques. Other sources of radiation also play a role in soft error rates. For example, naturally-occurring background radiation (such as from cosmic rays) has been shown to contribute to soft error rates, particularly at high altitudes.
In general, two major techniques have been employed to address soft errors. First, manufacturing processes have been improved to greatly reduce the introduction of radioactive isotopes into production lines. Second, error detection and correction techniques have been introduced into circuit designs. For example, memory designs often incorporate parity or error correcting code (ECC) techniques to allow detection and/or correction of at least single-bit errors. Although ECC techniques can be very effective in mitigating soft errors, they are not without cost. In particular, ECC techniques require extra storage and logic to implement. Unfortunately, the portion of a semiconductor chip (e.g., that for extra memory cells and circuitry) employed to provide error detection and/or correction is not available for other purposes. As a result, given a fixed die size, a processor that employs ECC in its on-chip cache will necessarily have to make do with a smaller on-chip cache than one that does not. Accordingly, a need exists for techniques that allow detection and/or mitigation of soft errors without sacrificing memory or cache size and without special ECC circuitry. Alternatively, a need exists for techniques that allow detection and/or mitigation of soft errors in existing processor or system configurations that may not include facilities for ECC.
Accordingly, it has been discovered that software techniques can be employed to mitigate soft errors. In particular, it has been discovered that a compiler (or other executable code generator) may emit otherwise duplicative instructions targeting otherwise duplicative storage locations to facilitate run-time detection and, in some cases, mitigation of soft errors. In general, a compiler emits a program sequence of primary instructions that correspond to source code. However, in addition, for those primary instructions that target storage susceptible to soft errors, the compiler may emit corresponding additional instructions that target additional storage. In some implementations the additional storage is not itself susceptible to soft errors. However, more generally, implementations may tolerate soft errors affecting the additional storage, as long as such soft errors are generally uncorrelated with those affecting the storage targeted by the primary instructions. In some realizations, the generally uncorrelated nature of single event upsets allows the additional storage targeted by the additional instructions and that targeted by the primary instructions to be separate locations within the same store or memory hierarchy.
Additional instructions may be emitted to allow detection of discrepancies in values read from storage targeted by the primary instructions and those read from the additional storage. In addition to detection, some realizations may provide facilities (in the form of additional instructions inserted in the program sequence) that allow soft errors to be corrected. For example, on detection of a discrepancy, such additional instructions may instruct the processor to branch backward in the program sequence to recompute values. As a statistical matter, we would not expect the recomputation to exhibit the same error. Alternatively, the additional instructions may instruct the processor to retrieve the value exhibiting the discrepancy from storage less susceptible to transient soft errors. For example, in the case of a write-through cache design, the processor could force the cache to refresh from main memory. In some configurations, main memory may be less susceptible to soft errors or may incorporate ECC.
Both compiler-type and translator-type realizations are contemplated. For example, in some realizations, existing executable code (e.g., binary or object code) may be translated into a corresponding executable program object that, in addition to the program sequence of instructions of the existing code, includes corresponding additional instructions inserted into the program sequence. As with the compiler-based techniques, these corresponding additional instructions target additional storage locations and thereby facilitate detection and/or correction of soft errors.
The present invention may be better understood, and its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings.
The use of the same reference symbols in different drawings indicates similar or identical items.
A variety of systems are envisioned that employ techniques of the present invention to detect and/or mitigate soft errors using duplicative instructions. For example, compilers, just in time (JIT) compilers, interpreters, binary-to-binary translation programs and other software systems may be employed to generate executable code in (or transform executable code into) a form in which soft-errors that would otherwise go undetected and potentially cause data corruption can, instead, be detected and/or mitigated through execution of extra instructions inserted into an execution path of the executable code. In this way, the compiler, just in time (JIT) compiler, interpreter or binary-to-binary translation program, rather than (or in addition to) fault tolerant hardware or system techniques provides error detection and/or mitigation.
In general, such techniques may be employed on a highly selective basis (e.g., targeting a specific known or suspected vulnerability) or more comprehensively throughout program code in accordance with the requirements of a particular application. For example, one particularly advantageous use of the invented technique is in mitigating a design weakness, instability, or susceptibility to transient soft errors that is discovered for parts or product in the field (e.g., a microprocessor shipped in a customer system). Accordingly, such a design weakness, instability, or susceptibility could be addressed through recompilation of at least selected program or operating system code using techniques such as described herein. Depending on the nature of the susceptibility, remedial compilation or binary translation could be limited to very narrow circumstances such as a relatively obscure instruction sequence or particular instruction and data store pairings. In cases where a susceptibility to transient error is a function of time in storage, such as in the case of an under margin defect transiently affecting cache or other storage, selection of instructions for duplication may be informed by liveness analysis performed by a compiler. Alternatively, a risk level may factor into selections. For example, risks associated with corruption of an address calculation may be judged to be higher than for data manipulations. Accordingly, address calculation instructions may be more likely to be selected for duplication. Depending on the type of soft error susceptibility, duplication may extend to storage locations in addition to instructions.
Compiler technology is well understood in the art. See e.g., Appel & Ginsburg, Modem Compiler Implementation in C, for a review of fundamentals. However, in summary, persons of ordinary skill in the art will understand application of the invented techniques in the illustrative context of
Instruction selection 114 identifies instructions of a target machine that correspond to portions of the intermediate representation. Control flow and data flow analyses are performed. In particular, a data flow analysis (e.g., 115) allows the compiler to determine the flow of information through variables of the program. By performing a liveness analysis, the compiler can determine the portion of an execution path during which a variable stores data that will be later used in a program sequence. Once liveness analysis has been performed, the compiler allocates (e.g., at 116) register storage so that live variables efficiently utilize finite storage resources. Finally, temporary names are resolved so that machine instructions refer to machine registers and code is emitted (e.g., code emission 117). Subsequent assembler and linker phases may be employed to generate a particular instance of executable program code.
The techniques of the present invention build on two facilities. First, selection of particular program constructs for duplication and second, insertion of auxiliary program functionality with duplicative instructions. In compiler realizations of the present invention, such facilities may operate at any of a variety of compilation phases. For example, in a typical implementation in accordance with the functional decomposition of
While the illustration of
In any case, compiler 110 (as an exemplary facility) takes a source language encoding 101 (e.g., Java™ programming language statements, “C” or “C++” source code, etc.) and performs operations to generate executable code 120 (e.g., SPARC™ architecture machine code, other processor object code, Java virtual machine bytecodes, etc.). In some embodiments, source language encoding 101 includes instructions encoded in computer readable media or received incrementally or in toto via communication media such as a local area, wide area or telecommunications network.
Java and all Java-based marks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SPARC architecture based processors are available from Sun Microsystems, Inc, Mountain View, Calif. SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the United States and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems.
A wide variety of criteria may be employed in the selection of program elements for duplication. In general, the employed criteria (e.g., selection criteria 102) are implementation dependent. In some implementations, selection criteria may narrowly target a specific known or suspected vulnerability. Alternatively, some implementations may cast a wider net and result in more comprehensive insertion of duplicative instructions throughout program code.
Selection criteria may target occurrences of a specific instruction, specific sequences of instructions, combinations of one or more specific instructions and register or other storage targets or sources, etc. Such criteria may be particularly appropriate in circumstances where mitigation of a design weakness, instability or timing hazard is known to (or suspected of) increasing a susceptibility to transient soft errors. Alternatively, selection criteria may include time in storage as a susceptibility factor. For example, some implementations may employ liveness analysis performed at least in part by the compiler or other transformation program to identify certain program variables for which a threshold level of temporal exposure to transient soft errors is exceeded. For example, a value maintained in a register or in cache for an extended period of time may be viewed as more likely than other values to have sustained a single event upset or an intervening supply voltage collapse and data corruption. Accordingly, time in storage may be a useful selection criterion in some cases. Analogously, at least for multicycle operations in which intermediate data paths or data stores may be vulnerable to transient soft errors, threshold number of iterations or cycles may be similarly be employed to select certain multicycle operations for duplication.
In addition or alternatively, a measure of risk or impact may be employed in some selection criteria. For example, address computations may be viewed as much higher risk than mere data manipulations in certain systems. For example, perturbation of even a single bit of a pointer, address or index may alter a branch target and therefore the execution path of a program, causing errant behavior, a memory system violation, trap or program halt. In like manner, instruction stream manipulations such as store-into-instruction-stream operations performed in systems that support dynamic recompilation or self-modifying code may present similarly high levels of risk. For example, perturbation of even a single bit of an instruction may result in errant behavior, an invalid instruction, trap or program halt.
Depending on the type or combination of selection criteria employed, selection and insertion of duplicative instructions are performed at (or use information from) an appropriate compiler stage or stages. Typically, final stages of a compiler (e.g., code emission and register allocation) are appropriate. However, in some implementations, selection and/or insertion are performed at earlier stages. For example, in implementations where additional register storage may be required, it may be useful to insert duplicative instructions and storage targets prior to register allocation. Similarly, as described above, liveness analysis from a dataflow analysis phase may be employed in some implementations.
Duplicative instructions 202 are spliced into the program sequence using any suitable mechanism. For example, in some realizations, duplicative instructions 202 are included in-line in program code. In others, a branch or branches (not specifically shown) may be added into the program code or instruction stream to augment the initial sequence of instructions. Persons of ordinary skill in the art will appreciate suitable variations for specific implementations. In the illustration of
Of course, some implementations may duplicate larger numbers of instructions or may include more complicated sets of duplicative instructions. While a strong correspondence typically exists between instructions and data stores of a pre-existing construct and those instructions and data stores employed in a set of duplicative instructions 202, mere functional equivalence is suitable for many implementations. Accordingly, the exact instructions and data store types need not be duplicated. In addition, a duplicative set of instructions need not be contiguous. Indeed, particularly in implementations that attempt to address lengthy exposure of data to transient errors, comparison of other detection instructions may be separated from those duplicative instructions that create a redundant copy of the data by large numbers of intervening instructions.
While the invention has been described with reference to various embodiments, it will be understood that these embodiments are illustrative and that the scope of the invention is not limited to them. Many variations, modifications, additions, and improvements are possible. For example, while compiler facilities have been used as a descriptive context, the invention is not limited thereto. Indeed, the other executable code generators including just-in-time compilers, binary translators, etc. may be employed. More generally, plural instances may be provided for components, operations or structures described herein as a single instance. Finally, boundaries between various components, operations and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of claims that follow. Structures and functionality presented as discrete components in the exemplary configurations may be implemented as a combined structure or component. These and other variations, modifications, additions, and improvements may fall within the scope of the invention as defined in the claims that follow.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US6125466 *||Nov 28, 1994||Sep 26, 2000||Cabletron Systems, Inc.||DRAM parity protection scheme|
|US6149318 *||Apr 15, 1997||Nov 21, 2000||Samuel C. Kendall||Link-time and run-time error detection, and program instrumentation|
|US6615366 *||Dec 21, 1999||Sep 2, 2003||Intel Corporation||Microprocessor with dual execution core operable in high reliability mode|
|US6631493 *||Aug 8, 2002||Oct 7, 2003||International Business Machines Corporation||Method and apparatus for limiting soft error recovery in a disk drive data storage device|
|US6678837 *||Jun 30, 2000||Jan 13, 2004||Intel Corporation||Processor control flow monitoring using a signature table for soft error detection|
|US6748589 *||Oct 20, 1999||Jun 8, 2004||Transmeta Corporation||Method for increasing the speed of speculative execution|
|US6766428||Apr 6, 2001||Jul 20, 2004||Sun Microsystems, Inc.||Method and apparatus for storing prior versions of modified values to facilitate reliable execution|
|US6779087||Apr 6, 2001||Aug 17, 2004||Sun Microsystems, Inc.||Method and apparatus for checkpointing to facilitate reliable execution|
|US6785847 *||Aug 3, 2000||Aug 31, 2004||International Business Machines Corporation||Soft error detection in high speed microprocessors|
|US6845472 *||Jan 25, 2001||Jan 18, 2005||Hewlett-Packard Development Company, L.P.||Memory sub-system error cleansing|
|US6862151 *||Jun 28, 2001||Mar 1, 2005||Seagate Technologies Llc||Method and apparatus for read error recovery|
|US20030023932 *||Mar 29, 2001||Jan 30, 2003||International Business Machines Corporation||Method and apparatus for parity error recovery|
|US20040153763 *||Sep 2, 2003||Aug 5, 2004||Grochowski Edward T.||Replay mechanism for correcting soft errors|
|1||Mueller et al., "RAS strategy for IBM S/390 G5 and G6", IBM J. Res. Develop., vol. 43, No. 5/6, pp. 875-888, Sep./Nov. 1999.|
|2||Ziegler, J.F. et al., "IBM experiments in soft fails in computer electronics (1978-1994)", 12 pages, obtained at http://www.research.ibm.com/journal/rd/ziegl/zieglrt.htm; printed on Feb. 13, 2001.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7654578 *||Jan 20, 2004||Feb 2, 2010||Leonhard Kurz Stiftung & Co. Kg||Security document comprising at least one security element|
|US8024639 *||Mar 27, 2007||Sep 20, 2011||Schweitzer Engineering Laboratories, Inc.||Software and methods to detect and correct data structure|
|US8176361 *||Aug 15, 2008||May 8, 2012||Nytell Software LLC||Data processing with protection against soft errors|
|US8271831||May 27, 2010||Sep 18, 2012||International Business Machines Corporation||Tolerating soft errors by selective duplication|
|US8448027||May 27, 2010||May 21, 2013||International Business Machines Corporation||Energy-efficient failure detection and masking|
|US8806452 *||Nov 10, 2011||Aug 12, 2014||International Business Machines Corporation||Transformation of computer programs and eliminating errors|
|US8898516 *||Dec 9, 2011||Nov 25, 2014||Toyota Jidosha Kabushiki Kaisha||Fault-tolerant computer system|
|US8990930||Feb 6, 2009||Mar 24, 2015||Microsoft Corporation||Code property analysis for security mitigations|
|US9122540||Jul 10, 2014||Sep 1, 2015||International Business Machines Corporation||Transformation of computer programs and eliminating errors|
|US20060119096 *||Jan 20, 2004||Jun 8, 2006||Werner Reinhart||Security document comprising at least one security element|
|US20070300121 *||Mar 27, 2007||Dec 27, 2007||Cooper Francis J||Software and Methods to Detect And Correct Data Structure|
|US20100205673 *||Feb 6, 2009||Aug 12, 2010||Microsoft Corporation||Code property analysis for security mitigations|
|US20110072303 *||Aug 15, 2008||Mar 24, 2011||Nxp B.V.||Data processing with protection against soft errors|
|US20130125098 *||Nov 10, 2011||May 16, 2013||International Business Machines Corporation||Transformation of Computer Programs|
|US20130151894 *||Dec 9, 2011||Jun 13, 2013||Toyota Infotechnology Center Co., Ltd.||Fault-Tolerant Computer System|
|U.S. Classification||717/143, 714/17, 717/141, 714/E11.018, 714/E11.008, 714/11, 714/31, 717/145|
|International Classification||G06F9/45, G06F11/00|
|European Classification||G06F11/00F, G06F11/14S4|
|Jun 26, 2002||AS||Assignment|
Owner name: SUN MICROSYSTEMS, INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SAULSBURY, ASHLEY N.;REEL/FRAME:013062/0263
Effective date: 20020624
|Mar 25, 2008||CC||Certificate of correction|
|Jul 13, 2011||FPAY||Fee payment|
Year of fee payment: 4
|Jul 29, 2015||FPAY||Fee payment|
Year of fee payment: 8
|Dec 16, 2015||AS||Assignment|
Owner name: ORACLE AMERICA, INC., CALIFORNIA
Free format text: MERGER AND CHANGE OF NAME;ASSIGNORS:ORACLE USA, INC.;SUN MICROSYSTEMS, INC.;ORACLE AMERICA, INC.;REEL/FRAME:037302/0899
Effective date: 20100212