CounterPoint: Using Hardware Event Counters to Refute and Refine Microarchitectural Assumptions

Modern CPUs expose thousands of hardware event counters that could, in principle, reveal how the chip works inside — but their specifications are vague, only a handful can be read at once (so measurements are noisy), and the web of relationships between them is too tangled to reason about by hand; this paper (Yale and Stanford — Nick Lindsay, Caroline Trippel, and colleagues) presents CounterPoint, which lets an expert write their mental model of the hardware as a decision-diagram graph, automatically derives every check that model implies, and tests those checks against noise-tolerant counter measurements to refute wrong assumptions and point toward the hidden features that explain the mismatch.

The argument in one glance

Problem

Thousands of hardware counters could reveal how a chip works, but nobody can read them clearly

Modern CPUs contain hardware event counters: tiny registers that tick up whenever some internal event happens — a cache miss, a page table walk, a branch misprediction. In principle they are a window into the microarchitecture, the hidden internal design of the chip, letting an expert learn how the hardware really behaves without access to the proprietary blueprints (RTL) or internal documentation. This matters because accurate mental models of hardware are what people use to build performance models and to calibrate the simulators that guide future chip design. And there are more counters than ever: x86-64 processors now expose thousands of them, more than a ten-times increase since 2009. But the promise is undermined by three practical problems. First, the counters are vaguely specified, so it is often unclear exactly what a given counter measures. Second, only a small number can be measured at the same time — typically four to eight physical counters — so to record thousands of logical counters the hardware time-shares them, and the resulting measurements are approximate, corrupted by what the paper calls multiplexing noise. Third, to interpret the counters you must know how they relate to each other, and the number of such relationships explodes as you use more counters. So the richest source of insight into a chip is, in practice, almost unreadable.
What people did

Reason about the counters by hand, one relationship at a time

The usual approach is manual and ad hoc: an expert writes down, from their mental model of the hardware, the relationships the counters ought to satisfy — for example, that on a design with a paging-directory cache consulted once per page table walk, the number of such cache misses should never exceed the number of walks. They then measure the counters on real hardware and check whether the expected relationship holds.
Why it fell short

Manual checks do not scale, and noise hides the violations that matter

This breaks down on real hardware and real counter sets. First, even a simple mental model implies many consistency checks — the paper calls each one a model constraint — and their number grows faster than linearly with the counters used: dozens of counters can imply dozens of intertwined constraints involving many counters at once, far too many to derive or reason about by hand. Worse, the constraints are easy to get subtly wrong, formulating them too loosely (so real violations slip through) or incorrectly. Second, even when a constraint truly is violated, multiplexing noise can hide it: because measurements are approximate, past a certain number of active counters it becomes impossible to tell, with confidence, whether a given constraint is actually broken. And third, the whole point of catching a violation is to learn from it — a broken constraint means the expert's mental model is wrong somewhere — but then the expert must revise the model and re-derive an entirely new, complex set of constraints, compounding the manual burden. What was missing was a way to generate all the constraints a model implies automatically, test them against noisy data reliably, and use the violations to guide refinement.
This paper's idea

Express the model as a decision diagram, derive every check, and test it noise-tolerantly

CounterPoint is a framework that tests an expert's microarchitectural model for consistency with counter data, and when they disagree, points to the hidden features that could explain the gap. It rests on three moves. First, instead of writing constraints directly, the expert describes their mental model as a graph — a micro-path Decision Diagram, a specialized directed acyclic graph that traces the execution paths a micro-operation can take through the hardware and which counters each path increments. From this graph CounterPoint automatically derives the model cone: the set of all counter-value combinations the model can produce, which is provably equivalent to all the model constraints, eliminating manual derivation. Second, because the diagram is expressed at the fine granularity of micro-operations, the derived constraints have naturally tight bounds, so even small deviations from the model show up as violations. Third, CounterPoint turns noisy, multiplexed measurements into tight counter confidence regions — ranges of true counter values inferred with high confidence — by exploiting the fact that counters are highly correlated (over a quarter of counter pairs in their data correlate above 0.9), which fights the noise far better than treating each counter independently. Feasibility testing then asks whether the confidence region and the model cone overlap: if not, the model is refuted, and CounterPoint reports which constraints failed, guiding the expert to revise the graph and iterate. Applied to the Intel Haswell memory management unit, CounterPoint uncovered several undocumented features, including a load-store-queue-side TLB prefetcher, merging and abortable page table walks, and a root-level page table cache.

Why this problem is worth solving

The counters are one of the only legitimate windows into a closed chip, and better mental models of that chip ripple outward into simulators and future designs.

Hardware event counters began in the 1980s as tools for performance tuning — find the bottleneck, speed up the code. But their role has grown: today they are used to calibrate microarchitectural simulators and build analytical models of hardware, which in turn guide the design of future processors. The reason this is so valuable is that the internal design of a commercial CPU is a closely guarded secret; the register-transfer-level blueprints and internal documentation are not public. The counters are one of the few legitimate, low-overhead ways for an outside expert to infer what the hardware actually does. Address translation is a striking example: some processors devote dozens of counters to it (IBM’s Power9 has 96 counters just for address translation), and researchers routinely try to use them to reverse-engineer how the translation hardware works so they can model it accurately. If the counters could be read reliably, experts could correct wrong assumptions baked into a decade of simulators and performance studies. So making the counters interpretable is not a niche tuning concern — it improves the models the whole field builds on.

What makes it genuinely hard is that the difficulty grows precisely as the counters get richer, in two compounding ways.

You might expect that having more counters would make the hardware easier to understand, but it cuts both ways. On one hand, a diverse set of counters is exactly what lets you catch a wrong assumption: you can only spot that a paging-cache assumption is violated because a specific counter for page walks exists on that chip; without it, you would be stuck with generic, uninformative counters. On the other hand, more counters make the reasoning explode. The number of consistency checks a mental model implies grows faster than linearly with the counters involved, and the checks become tangled, each relating many counters at once — quickly beyond what a person can derive correctly by hand. Simultaneously, more active counters mean more multiplexing noise, because the hardware has only a handful of physical counters and must time-share them; past a threshold, the noise is large enough that you can no longer tell whether a constraint is really violated. So the very richness that gives the counters their diagnostic power also makes them unmanageable manually and noisier to measure. Getting both under control at once — automatic constraint generation and noise-tolerant testing — is the core challenge.

What people did before, and where it broke

Write down expected counter relationships by hand. From a mental model, an expert states the relationships the counters should satisfy and checks them on real hardware. Where it broke. Even a simple model implies many constraints, and their number grows faster than linearly with the counters, so manual derivation becomes intractable and error-prone.
Formulate a few constraints and hope they are tight enough. Bound the counters with a handful of hand-written inequalities. Where it broke. Constraints are easy to write too loosely or incorrectly, so real violations slip through undetected and the model looks consistent when it is not.
Treat each counter’s noise independently. Handle multiplexing noise by putting an error bar on each counter on its own. Where it broke. Independent error bars are far too wide; past a certain number of active counters, genuine constraint violations can no longer be distinguished from noise.
Reverse-engineer specific features ad hoc. Target one suspected behavior (say, a prefetcher) with bespoke microbenchmarks. Where it broke. These one-off efforts are laborious, hard to compose, and miss subtle interactions between features that only show up when many counters and constraints are considered together.
The gap. No framework could automatically generate all the constraints a microarchitectural model implies, test them reliably against noisy multiplexed counters, and use the violations to guide systematic refinement of the model.

How CounterPoint works

From a mental model to refuted assumptions and hidden features

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Test a black-box chip against a stated model to find where reality violates it. CounterPoint’s core stance is adversarial in the useful sense: the expert commits to a precise model of how the hardware should behave, and the framework hunts for measurements that the model cannot explain, exposing the gap between assumption and silicon. Pinning a black-box processor against an explicit specification and searching for observable behavior that the specification forbids is the same undertaking the work on testing black-box CPUs against speculation contracts (Revizor) covered elsewhere on this site pursues, treating a mismatch as evidence the model is incomplete. CounterPoint does this with performance counters and microarchitectural models, so a refuted model constraint becomes a lead toward a hidden feature rather than just a bug.

Encode the model as a decision diagram a tool can analyze mechanically. Rather than asking the expert to enumerate constraints, CounterPoint has them draw the model as a micro-path Decision Diagram — a compact graph whose paths a formal tool can walk to derive every consequence automatically. Choosing a decision-diagram representation precisely because it lets an automated engine explore an enormous space of behaviors compactly is the same principle the work on batch quantum circuit simulation using decision diagrams (BQSim) covered elsewhere on this site is built on, letting the structure of the diagram carry the combinatorial load. CounterPoint uses the diagram to enumerate micro-operation paths and the counters they increment, and proves the resulting model cone captures exactly the model’s constraints.

Draw reliable conclusions from noisy signals with statistical confidence. Because only a few counters can be measured at once, every measurement is noisy, so CounterPoint never trusts a single reading; it builds confidence regions and reports violations only at a stated confidence level. Replacing a fragile point measurement with a statistically bounded range, and acting only when the evidence clears a confidence threshold, is the same idea the work on early termination for hyperdimensional computing using inferential statistics covered elsewhere on this site develops, letting statistics separate a real signal from noise. CounterPoint sharpens this by exploiting the correlations between counters, which yields tighter regions and lets it detect over 24 percent more genuine violations than assuming the counters vary independently.

Following a discovery through CounterPoint

Refuting an assumption and refining the model of the Haswell MMU

A trace, drawn from the paper's case study, of how CounterPoint uncovers a hidden feature.

Step 1 of 5

The expert writes a mental model in the language

The expert encodes an assumption about the Haswell memory management unit — for instance, that the paging-directory cache is consulted exactly once per page table walk, so its misses can never exceed the number of walks.

This is a natural, widely held assumption baked into many simulators.

Why it works

A diagram lets a tool derive the constraints instead of a person. Manual constraint derivation explodes faster than linearly with counters → but describing the model as a decision diagram lets CounterPoint derive the model cone automatically → so the intractable bookkeeping is handled by the tool, not the expert.
Micro-operation granularity makes the bounds tight. Loose constraints let real deviations slip through → but expressing the model at the level of individual micro-operations yields naturally tight upper and lower bounds → so even small mismatches with reality register as violations.
The model cone tests every constraint at once. Checking constraints one by one is slow and scales badly → but the model cone represents all of them geometrically → so a single feasibility test covers dozens of counters and constraints simultaneously.
Exploiting counter correlations beats the multiplexing noise. Independent error bars are too wide to catch violations → but counters are highly correlated (many pairs above 0.9), and confidence regions exploit this → so the inferred ranges are tight enough to reveal over 24 percent more violations, up to 75 percent for some models.
Every refutation is a lead toward a hidden feature. A violated constraint just says the model is wrong somewhere → but CounterPoint reports which constraints failed → so the expert knows what to add to the diagram, turning refutation into systematic discovery.

What it costs (trade-offs and scope)

It refines models; it does not invent them. CounterPoint tests and refutes the expert’s proposed diagram and guides refinement, but the hypotheses come from the expert. It sharpens and accelerates human insight rather than replacing it, so the quality of the discoveries still depends on the models proposed.
It can only distinguish what the available counters expose. Some behaviors it flagged — such as page table walks that complete without any memory accesses (possible replays) — cannot be fully pinned down from counters alone, and would require new counters or access to proprietary RTL to resolve.
Deriving the full constraint set is computationally expensive. Explicitly computing the constraints scales exponentially with the number of counter groups (taking from under a second up to about ten seconds), and evaluating a model averages around 213 seconds; feasibility testing itself is cheaper (about 200 milliseconds per observation) and parallelizable, but the analysis is not free.
The findings are a single-microarchitecture case study. The discoveries are specific to the Intel Haswell memory management unit; the authors present it as a foundation and argue the approach extends to other components and newer chips, but that extension is future work.
Conclusions are statistical, not proofs. Violations are reported at a confidence level (99 percent) and depend on collecting enough correlated data across workloads that exercise the behavior; a poorly-covered behavior may not produce a detectable violation, and a claim is a high-confidence inference, not a certainty.

The evaluation

Interpreting hardware event counters, by hand versus with CounterPoint

Property	Manual, ad hoc analysis	Independent-noise error bars	CounterPoint
Generating model constraints
Tightness of constraints
Handling multiplexing noise
Violations detected
Outcome on the Haswell MMU

A comparison of ways to interpret hardware event counters. CounterPoint automatically derives all model constraints from a decision-diagram description, keeps them tight by working at micro-operation granularity, and uses correlation-aware confidence regions to see through multiplexing noise — detecting over 24 percent more genuine violations than independent error bars (up to 75 percent for some models) and revealing several undocumented features of the Intel Haswell memory management unit.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

This explainer is based on the paper’s full text (the authors’ extended arXiv version of the ASPLOS 2026 paper). The framework described is the paper’s: CounterPoint tests user-specified microarchitectural models — expressed as micro-path Decision Diagrams — for consistency with performance-counter data, and when mismatches occur, points to plausible microarchitectural features that could explain them, using multi-dimensional counter confidence regions to mitigate multiplexing noise. It derives the model cone (equivalent to all model constraints) from the diagram via convex geometry, builds tight confidence regions by exploiting correlations between counters, and reports constraint violations through feasibility testing to guide iterative refinement. Applied to the Intel Haswell memory management unit as a case study, the paper reports uncovering several undocumented or underdocumented behaviors, including a load-store-queue-side TLB prefetcher (with specific trigger conditions, and prefetch-induced walks that abort when an access bit is unset), page table walk merging via MMU miss-status holding registers, abortable walks, page table walks that complete without memory accesses, and a root-level page table cache. Reported quantitative results include over 24 percent more violations detected using correlated confidence regions (over 75 percent for some models), over a quarter of counter pairs correlating above 0.9, an average model-evaluation time near 213 seconds, and an initial model with 31 constraints of which 8 were violated. Exact algorithms, the formal definitions and proofs, the full set of discoveries, and all results should be read from the paper.

Background

Why understanding closed hardware from the outside is a recurring struggle

It helps to see CounterPoint within a long tradition of trying to understand hardware that its makers will not fully explain. Commercial processors are among the most complex artifacts ever built, and their internal designs are trade secrets, so the people who must reason about them — performance engineers, simulator builders, security researchers — are perpetually working from the outside, inferring structure from whatever the chip is willing to reveal. Over the years that has meant timing measurements, microbenchmarks that probe one suspected feature at a time, and careful statistical inference, each fighting the same enemies: the hardware’s opacity and the noise in any external measurement. The stakes are high because so much downstream work — simulators used to design the next generation, models used to predict performance, analyses used to find vulnerabilities — rests on these inferred mental models being correct, and a wrong assumption can quietly invalidate years of results. Address translation is a particularly consequential corner of this, since the memory management unit sits on the critical path of nearly every memory access. The broader effort to model and improve how processors translate addresses is the same terrain the work on direct memory translation for virtualized clouds covered elsewhere on this site occupies, working on the very hardware whose hidden behavior CounterPoint reverse-engineers. CounterPoint’s contribution is to make this outside-in understanding rigorous and systematic: rather than probing one feature at a time and hoping the noise cooperates, it lets an expert state a full model, mechanically confront it with the data, and follow the refutations to the truth.

If you remember only three things

1. Modern CPUs expose thousands of hardware event counters that could reveal their hidden internal design, but the promise is undermined by vague specifications, multiplexing noise (only four to eight counters can be read at once, so measurements are approximate), and the fact that the consistency checks a mental model implies grow faster than linearly with the counters used. Manual, ad hoc analysis cannot derive or test all these checks, and noise can hide the very violations that would reveal a wrong assumption.
2. CounterPoint lets an expert describe their model as a micro-path Decision Diagram (a specialized directed acyclic graph tracing the paths a micro-operation takes and the counters each increments). It automatically derives the model cone — provably equivalent to all the model constraints — so no constraint is written by hand; because the diagram works at micro-operation granularity the constraints are tight; and it turns noisy measurements into confidence regions that exploit the strong correlations between counters, detecting over 24 percent more genuine violations (up to 75 percent for some models) than independent error bars. Feasibility testing then refutes inconsistent models and points to the features that would fix them.
3. Applied to the Intel Haswell memory management unit, CounterPoint uncovered several undocumented features: a load-store-queue-side TLB prefetcher with specific triggers, prefetch-induced walks that abort when an access bit is unset, page table walk merging, abortable walks, and a root-level page table cache — overturning assumptions baked into a decade of simulators. The trade-offs: it refines models rather than inventing them, can only distinguish what the available counters expose, is computationally heavy (constraint derivation grows exponentially with counter groups), reports statistical rather than certain conclusions, and its findings so far are a single-microarchitecture case study.

Check yourself

Check your understanding

1. Why are hardware event counters hard to use for understanding a CPU's internal design, despite there being thousands of them?
2. What is a micro-path Decision Diagram, and why does CounterPoint have experts use it instead of writing constraints directly?
3. How does CounterPoint cope with the multiplexing noise that would otherwise hide constraint violations?
4. Predict: an expert runs CounterPoint, and it reports that a model constraint is violated. What has CounterPoint actually told them, and what should they do next?

Sources

The paper is “CounterPoint: Using Hardware Event Counters to Refute and Refine Microarchitectural Assumptions” by Nick Lindsay, Caroline Trippel, Anurag Khandelwal, and Abhishek Bhattacharjee (Yale University and Stanford University), published at ASPLOS 2026, DOI 10.1145/3779212.3790145. An extended author version is available at arXiv:2601.01265.

This explainer is written from the paper’s full text (the authors’ extended arXiv version). Hardware event counters could reveal detailed microarchitectural behavior, but vague specifications, opaque designs, and multiplexing noise make them hard to interpret. CounterPoint is a framework that tests user-specified microarchitectural models — expressed as micro-path Decision Diagrams, specialized directed acyclic graphs capturing the execution paths micro-operations take and the counters they increment — for consistency with performance-counter data. It derives the model cone (all counter-value combinations the model can produce, provably equivalent to the model’s constraints) via convex geometry, mitigates multiplexing noise with multi-dimensional counter confidence regions that exploit correlations between counters, and uses feasibility testing to report which constraints are violated, guiding iterative refinement of the model. Applied to the Intel Haswell memory management unit as a case study, CounterPoint uncovered several undocumented and underdocumented behaviors, including a load-store-queue-side TLB prefetcher, merging page table walkers, abortable page table walks, page table walks that complete without memory accesses, and a root-level page table cache. Reported results include detecting over 24 percent more constraint violations with correlated confidence regions (over 75 percent for some models), over a quarter of counter pairs correlating above 0.9, and an average model-evaluation time near 213 seconds. Numbers and findings are the paper’s own; exact algorithms, definitions, proofs, and the full set of discoveries should be confirmed in the paper.