Microprocessor Verification via Feedback-Adjusted Markov Models

Abstract

Abstract-The challenge of verifying a modern microprocessor design is an overwhelming one: Increasingly complex microarchitectures combined with heavy time-to-market pressure have forced microprocessor vendors to employ immense verification teams in the hope of finding the most critical bugs in a timely manner. Unfortunately, too often, size does not seem to matter in verification, as design schedules continue to slip and microprocessors find their way to the marketplace with design errors. In this paper, we describe a novel closed-loop simulation-based approach to hardware verification and present a tool called StressTest that uses our methods to locate hard-to-find corner-case design bugs and performance problems. StressTest is based on a Markov-model-driven random instruction generator with activity monitors. The model is generated from the user-specified template files and is used to generate the instructions sent to the design under test (DUT). In addition, the user specifies key activity nodes within the design that should be stressed and monitored throughout the simulation. The StressTest engine then uses closed-loop feedback techniques to transform the Markov model into one that effectively stresses the user-selected points of interest. In parallel, StressTest monitors the correctness of the DUT response and, if the design behaves against expectation, it reports a bug and a trace leading to it. Using two microarchitectures as example testbeds, we demonstrate that StressTest finds more bugs with less effort than open-loop random instruction test generation techniques.

Improving Coverage of Simulation-Based Verification by Dedicated Stimuli Generation

“…Beyond that, stimuli generators (see e.g. [8], [9], [10]) have been presented aiming to keep the number of stimuli as small as possible. The approach presented in [10] even allows for deriving a minimal set of stimuli.…”

“…Then, in cooperation with modern stimuli generators (see e.g. [8], [9], [10]), this information can be exploited to generate particular stimuli covering these gaps and, by this, guide the subsequent verification in order to improve the coverage.…”

Analyzing Efficacy of Constrained Test Program Generators - A Case Study

“…Coverage-driven test generation [4] is an approach to analyze coverage results dynamically and automatically adapt the test generation process to improve coverage. One-class support vector machine [2] and genetic algorithms [3] have been used in recent works to learn from simulation results. However, automatically modifying the input to the test generator based on the feedback from simulation can be very difficult for complex designs in practice.…”

“…2) is to locate events not triggered. [1] asid[0] asid [1] asid [1] asid [1] asid [5] asid [2] asid[0] asid [2] asid [2] asid [2] asid [5] asid [3] asid[0] asid [3] asid [3] asid [4] asid[0] asid [4] asid [4] asid [5] asid[0] asid [5] asid [5] asid [6] asid[0] asid [6] asid [ [1] asid[0] asid [1] asid [1] asid [2] asid[0] asid [2] asid [2] asid [3] asid[0] asid [3] asid [3] asid [4] asid[0] asid [4] asid [4] asid [5] asid[0] asid [5] asid [5] asid [6] asid[0] asid [6] asid [ The definition of these untriggered/partially triggered coverpoints describe the exact events that were missed, in terms of signals.…”

Pre-Silicon Bug Forecast

“…Strongly relying on experiences of designers, such ad-hoc rules may take a high risk of wasting resources on bugfree modules, or missing bugs in buggy modules. Although coverage-centric verification (e.g., coverage-directed [11], [38] and coverage-oriented verification [13], [14]) may alleviate the above burden, even 100% coverage does not indicate a module to be bug-free, because coverage models (especially the widely used functional coverage model) still rely heavily on designer's experiences, and typically only cover a subset of functional components that are thought to be most vulnerable in a module.…”