Phoenix: Detecting and Recovering from Permanent Processor Design Bugs with Programmable Hardware

Abstract

Although processor design verification consumes ever-increasing resources, many design defects still slip into production silicon. In a few cases, such bugs have caused expensive chip recalls. To truly improve productivity, hardware bugs should be handled like system software ones, with vendors periodically releasing patches to fix hardware in the field.Based on an analysis of serious design defects in current AMD, Intel, IBM, and Motorola processors, this paper proposes and evaluates Phoenix -novel field-programmable on-chip hardware that detects and recovers from design defects. Phoenix taps key logic signals and, based on downloaded defect signatures, combines the signals into conditions that flag defects. On defect detection, Phoenix flushes the pipeline and either retries or invokes a customized recovery handler. Phoenix induces negligible slowdown, while adding only 0.05% area and 0.48% wire overheads. Phoenix detects all the serious defects that are triggered by concurrent control signals. Moreover, it recovers from most of them, and simplifies recovery for the rest. Finally, we present an algorithm to automatically size Phoenix for new processors.

Online design bug detection: RTL analysis, flexible mechanisms, and evaluation

“…Note that these numbers are much higher than previous work estimates that used high-level errata documentation to analyze design bugs. Specifically, the study in [20] reports that on average, for the ten processors studied, only 210 signals need to be monitored to detect all design bugs in all modules of a processor, with the maximum requirement out of the ten microprocessors being 260 signals. The study in [17] reports that monitoring only 41 signals is adequate to detect the occurrence of 43 out of the 63 known design bugs in the AMD Athlon 64 and AMD Opteron microprocessors.…”

“…More recently, Sarangi et al [20] analyzed the design bugs in ten modern commercial microprocessors from Intel, AMD, IBM and Motorola, and Narayanasamy et al [17] analyzed the design bugs in two microprocessors: Intel's Pentium 4 and AMD's Athlon 64. Another study by Wagner et al [26] analyzed the design bugs in Intel StrongARM SA1100 and IBM PowerPC 750GX.…”

“…Fortunately, not all design bugs are critical to functional correctness and need to be covered. Sarangi et al [20] studied the errata documentation of ten modern microprocessors and found that, on average for all the studied processors, 64% of the design bugs are critical to functional correctness. The remaining 36% of the design bugs were found to be non-critical to the correctness of the system and commonly located in modules such as performance counters, error reporting registers, or breakpoint support [20].…”

Controlled execution of complex systems

“…Этот подход [5] основывается на использовании в микросхеме процессора контролирующих программируемых схем с тем, чтобы нейтрализовывать аппаратные ошибки без замены микросхем. Существует некоторая последовательность действий, порождающая ошибку.…”

Tamper Evident Microprocessors

“…The state of practice is to ensure that hardware comes from a trusted source and is maintained by trusted personnel -a virtual impossibility given the current design and manufacturing realities. In fact, our inability to catch accidental bugs with traditional design and verification procedures, even in high-volume processors [59], makes it unlikely that hidden backdoors will be caught using the same procedures, as this is an even more challenging task. 3 In this paper we investigate how microprocessor trust can be strengthened when manufactured via an untrusted design flow.…”