A Mechanism for Online Diagnosis of Hard Faults in Microprocessors

Abstract

We develop a microprocessor design that tolerates hard faults, including fabrication defects and in-field IntroductionAs technological trends continue to lead toward smaller device and wire dimensions in integrated circuits, the probability of hard (permanent) faults in microprocessors increases. These faults may be introduced during fabrication, as defects, or they may occur during the operational lifetime of the microprocessor. Well-known physical phenomena that lead to operational hard faults are gate oxide breakdown, electromigration, and thermal cycling. Microprocessors become more susceptible to all of these phenomena as device dimensions shrink [28], and the semiconductor industry's roadmap has identified both operational hard faults and fabrication defects (which we will collectively refer to as "hard faults") as critical challenges [13]. In the near future, it may no longer be a cost-effective strategy to discard a microprocessor with one or more hard faults, which is what, for the most part, we do today.Traditional approaches to tolerating hard faults have masked them using macro-scale redundancy, such as triple modular redundancy (TMR). TMR is an effective approach, but it incurs a 200% overhead in terms of hardware and power consumption. There are some other, lightweight approaches that use marginal amounts of redundancy to protect specific portions of the microprocessor, such as the cache [36,18] or buffers [5], but none of these are comprehensive.Our goal in this work is to create a microprocessor design that can tolerate hard faults without adding significant redundancy. The key observation, made also by previous research [25,27,29], is that modern superscalar microprocessors, particularly simultaneously multithreaded (SMT) microprocessors [32], already contain significant amounts of redundancy for purposes of exploiting ILP and enhancing performance. We want to use this redundancy to mask hard faults, at the cost of a graceful degradation in performance for microprocessors with hard faults. In this paper, we do not consider adding extra redundancy strictly for fault tolerance, because cost is such an important factor for commodity microprocessors. The viability of our approach depends only on whether, given a faulty microprocessor, being able to use it with somewhat degraded performance provides any utility over having to discard it. To achieve our goal, the microprocessor must be able to do three things while it is running.• It must detect and correct errors caused by faults (both hard and transient).• It must diagnose where a hard fault is, at the granularity of the field deconfigurable unit (FDU).• It must deconfigure a faulty FDU in order to prevent its fault from being exercised.

A Hardware Framework for Yield and Reliability Enhancement in Chip Multiprocessors

“…An existing scheme that can be used for this purpose is the hard-fault detection and diagnosis framework described in [36], involving a low-cost hardware checker [38] and saturating counters. This section provides a brief outline of the methodology in [36] for the sake of completeness. The work here has no contributions towards this end.…”

“…If an instruction result is found to be erroneous, the faulty FDU in use is recorded by incrementing a saturating counter corresponding to each and every FDU used by the instruction. If the fault-count for an FDU rises beyond a threshold within a pre-specified time interval, the fault in that unit is considered to be permanent [36]. Experimental results indicate that most hard faults can be suitably detected and diagnosed within a few thousand instructions after the faults develop.…”

Architectural core salvaging in a multi-core processor for hard-error tolerance

“…One proposal for run-time isolation is BlackJack [20], which exploits simultaneously-redundant threads on an SMT, previously used to detect soft errors, to detect defects. Bower et al in [3] propose using DIVA-checkers, small auxiliary cores that check committed instructions [1], for defect isolation. Constantinides et al in [6] propose a virtualization layer between the operating system and the hardware to introduce periodic special instructions for defect isolation.…”

Software-Based Online Detection of Hardware Defects Mechanisms, Architectural Support, and Evaluation

“…The final phase (Step 3) of the test routine uses the ACE get instruction to read and validate the test response from the scan state. If a test pattern fails to produce the correct response at the end of Step 3, the test program indicates which part of the hardware is defective 5 and disables it through system reconfiguration [27,8]. If necessary, the test program can run additional test patterns to narrow down the defective part to a finer granularity.…”