Skip to content
STIMSMITH

Bare-metal exerciser

Concept WIKI v1 · 7/28/2026

A bare-metal exerciser is a post-silicon stimuli-generation and verification tool that runs directly on the silicon design under verification (DUV) without the support of an operating system. It continuously generates test-cases, executes them, and checks their results in an endless loop, providing a self-contained, long-running solution well suited to the lengthy loading and initialization times of silicon platforms.

Bare-metal exerciser

Definition

A bare-metal exerciser is a type of exerciser used in post-silicon validation that operates directly on the silicon itself, without relying on an operating system. It is a self-contained verification tool that generates test-cases, executes them on the design under verification (DUV), checks their results, and provides the OS-like services required by those test-cases [1][2].

The term "bare-metal" emphasizes that the exerciser image itself includes a thin OS-like layer of basic services so that it can run before an operating system is available on the device [3].

Motivation in post-silicon validation

Post-silicon validation is hampered by the long loading and initialization times of real silicon. A 10,000-instruction test-case may complete in under a millisecond on an advanced processor, while preparing the processor for execution (power-on, loading the test-case into memory, etc.) can take more than a minute, yielding an execution utilization of less than 0.002% [1].

Because of this imbalance, post-silicon validation tends to rely on longer-running solutions such as exercisers, which run in an endless loop and are only loaded once onto the DUV [1].

Structure

The exerciser image is composed of three major components [3]:

  1. A thin, OS-like layer of basic services that enables bare-metal execution.
  2. A representation of the test-template, architectural model, and system configuration description as simple data structures.
  3. Fixed (test-template independent) code responsible for exercising.

The builder combines these components into an executable image that is loaded onto the silicon platform. Once loaded, the exerciser indefinitely repeats the cycle of generating a random test-case based on the test-template, configuration, and architectural model, executing it, and checking its results [3].

Key requirements

The post-silicon environment imposes several requirements on a bare-metal exerciser [4][2]:

  • Simplicity of software. Hardware failures are hard to debug, so simple software is needed to ease debug effort, and the tool must be deployable at very early post-silicon stages when no OS is available and I/O operations such as reading files are not supported.
  • Low generation/checking overhead. The ratio between time spent generating and checking a test-case and the time spent running it must be kept low. For example, embedding a full reference model inside an exerciser could improve checking but would be complex software that significantly reduces platform utilization.
  • Fast, simple generation engine. The heavy, sophisticated generation engines typical of pre-silicon generators (which can use a reference model) must be replaced by a lighter and faster engine to avoid spending more time on generation than on execution of the tests.
  • Continuous (endless-loop) operation. To amortize the long load time, the exerciser continuously generates, runs, and checks new test-cases after a single load.
  • Limited observability. Unlike simulation, silicon provides limited observability for checking and coverage measurement. Coverage can still be measured by running the exerciser on an acceleration platform, where higher observability is available [4].

Reference-model handling

Reference models are an essential part of pre-silicon generation and checking because they give the generator an accurate view of the DUV's architectural state, enabling it to bias stimuli toward interesting events [4]. In a bare-metal exerciser, embedding such a model is impractical because of its complexity and its impact on utilization [2]. Instead, lightweight techniques are used:

  • Reloading resources (such as registers) can partially substitute for a reference model, though it may interfere with the generation of requested scenarios.
  • For data-oriented events (e.g., divide-by-zero), interesting values can be reserved in dedicated registers, provided the generator guarantees those registers are not modified during the test [3].

Example: Threadmill

Threadmill is a concrete implementation of a bare-metal exerciser developed to enable a unified pre-silicon / post-silicon verification methodology [1][2]. Threadmill is a directable random generator with a simple and fast generation engine; its test generation is static and does not rely on a reference model [3][2]. It was first applied to the verification and bring-up of the IBM POWER7 processor, where its use on accelerators provided significant help in finding bugs and produced a good set of test-templates that supported a smooth bring-up [2].

Role in the verification flow

In a unified verification methodology, bare-metal exercisers (and other exercisers) are deployed on accelerators as part of an "Exercisers on Accelerators" (EoA) phase that runs in parallel with simulation, starting as soon as the core is sufficiently stable and continuing after every tape-out in the post-silicon validation phase [3]. Coverage measured on accelerators is folded into the project's coverage reports alongside unit and core simulation coverage, and accelerator coverage is used to harvest high-quality test-templates for post-silicon validation [3].

Because the same test-template language can be used for pre- and post-silicon platforms, a bug detected on the silicon platform can be narrowed down in the test-template and replayed on the simulation platform to ease root-cause analysis [3].

See also

LINKED ENTITIES

2 links
Threadmill IMPLEMENTS
post-silicon validation USES

CITATIONS

10 sources
10 citations
[1] A bare-metal exerciser operates on the silicon itself without the support of an operating system. A Unified Methodology for Pre-Silicon Verification and Post-Silicon Validation
[2] An exerciser is a self-contained solution that generates test-cases, runs them, does the checking, and contains OS services required by the test-cases; it runs in an endless loop and is only loaded once on the DUV. A Unified Methodology for Pre-Silicon Verification and Post-Silicon Validation
[3] Silicon platforms suffer from long loading and initialization time (e.g., over a minute for a 10,000-instruction test-case), leading to very low execution utilization and motivating endless-loop exercisers. A Unified Methodology for Pre-Silicon Verification and Post-Silicon Validation
[4] The exerciser image consists of a thin OS-like layer for bare-metal execution, simple data structures representing the test-template, architectural model and configuration, and fixed test-template-independent exercising code; once loaded it indefinitely generates, executes, and checks random test-cases. A Unified Methodology for Pre-Silicon Verification and Post-Silicon Validation
[5] Post-silicon exercisers must be simple, run without an OS or I/O support, and keep the ratio of generation/checking time to execution time low; embedding a reference model is generally avoided because its complexity reduces platform utilization. A Unified Methodology for Pre-Silicon Verification and Post-Silicon Validation
[6] Without a reference model, Threadmill substitutes partial replacements such as reloading registers and reserving registers with interesting values (e.g., for data-oriented events like divide-by-zero) while ensuring those registers are not modified during the test. A Unified Methodology for Pre-Silicon Verification and Post-Silicon Validation
[7] Pre-silicon generators use a reference model to maintain an accurate view of processor state and bias stimuli toward interesting events; this is not practical inside a bare-metal exerciser. A Unified Methodology for Pre-Silicon Verification and Post-Silicon Validation
[8] Threadmill is a directable, bare-metal exerciser with a simple and fast static test-generation engine that does not rely on a reference model. A Unified Methodology for Pre-Silicon Verification and Post-Silicon Validation
[9] Running exercisers on accelerators provides coverage feedback that is merged into project coverage reports and used to harvest high-quality test-templates for the silicon bring-up team. A Unified Methodology for Pre-Silicon Verification and Post-Silicon Validation
[10] Coverage can be measured for a post-silicon exerciser by running it on an acceleration platform, which provides the observability not available on silicon. A Unified Methodology for Pre-Silicon Verification and Post-Silicon Validation