Application-Aware diagnosis of runtime hardware faults

Abstract

Extreme technology scaling in silicon devices drastically affects reliability, particularly because of runtime failures induced by transistor wearout. Current online testing mechanisms focus on testing all components in a microprocessor, including hardware that has not been exercised, and thus have high performance penalties.We propose a hybrid hardware/software online testing solution where components that are heavily utilized by the software application are tested more thoroughly and frequently. Thus, our online testing approach focuses on the processor units that affect application correctness the most, and it achieves high coverage while incurring minimal performance overhead. We also introduce a new metric, Application-Aware Fault Coverage, measuring a test's capability to detect faults that might have corrupted the state or the output of an application. Test coverage is further improved through the insertion of observation points that augment the coverage of the testing system. By evaluating our technique on a Sun OpenSPARC T1, we show that our solution maintains high Application-Aware Fault Coverage while reducing the performance overhead of online testing by more than a factor of 2 when compared to solutions oblivious to application's behavior. Specifically, we found that our solution can achieve 95% fault coverage while maintaining a minimal performance overhead (1.3%) and area impact (0.4%).

Cardio: CMP Adaptation for Reliability Through Dynamic Introspective Operation

“…Here, hardware components are tested at regular intervals in order to detect faults such as stuck-at, bridge or pathdelay [30]- [32]. In these systems, execution is partitioned into computational epochs, and workload execution is periodically suspended to test the underlying hardware components.…”

“…Cardio adopts this second execution paradigm for reliable computing, since it has been shown to be both very economical, as low as 1% hardware overhead [32], and effective in achieving high fault coverage [30]. Hence, this paper targets runtime hardware failures that can be detected by such periodic checks.…”

“…In our design, more frequent diagnostic tests lead to more prompt reactions to failures, but also entail higher performance impacts and diagnostic message proliferation. Indeed, diagnostic frequency is a design trade-off that we analyze in Section V. Since Cardio's objective is to dynamically react to detected permanent hardware faults, we rely on previously proposed techniques to diagnose faulty hardware components, such as those presented in [22], [32], and [38].…”

Viper: Virtual pipelines for enhanced reliability

“…As Viper's goal is to maximize processor availability in the face of hardware faults, we assume that other mechanisms will detect faulty hardware components [17,23,31]. In our failure model, we assume that a hardware component detected as faulty can be disabled.…”

“…Recent research on reliable processors has focused on online tests [23], fault isolation [12], redundant functional units [31] and runtime checks [1,20]. Though these solutions improve reliability, they still rely on centralized control logic: a single point of failure that can allow one fault to disable an entire core.…”