Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • Architecture Metrics Reference
  • Workload Taxonomy for Architects
  • Architecture Glossary
  • Computer Architecture Cheatsheet
  • Pipeline Fundamentals14
  • Memory Hierarchy15
  • NoC and Interconnect Architecture6
  • Coherency and Memory Ordering9
  • Performance Analysis9
    • Performance Method: Counters, Top-Down and Triage
      • What a PMU Counts
      • CPI, IPC, MPKI and Derived Metrics
      • Multiplexing, Denominators and Trust
      • Top-Down Bottleneck Attribution
      • Freeze the Workload, One Experiment, Replay
    • Roofline and Tuning
  • Accelerator Architectures6
  • SoC Architecture Tradeoffs9
  • Architecture Interview Prep14
Loading lesson

‹Performance Method: Counters, Top-Down and Triage
  1. Topics
  2. Computer Architecture
  3. Performance Analysis
  4. Performance Method: Counters, Top-Down and Triage
  5. What a PMU Counts

Computer Architecture · All levels

What a PMU Counts

What a PMU counts: fixed and programmable events, overflow, privilege gates, and per-core versus system scope.

On this page

    What a PMU counts

    A performance monitoring unit (PMU) counts microarchitectural events such as retired instructions, cycles, cache misses, and branch mispredicts. Fixed-function counters track a small set of common events with no setup.

    Programmable counters track a selected event each, chosen from the microarchitecture event list. This topic covers method only, never vendor event maps.

    These are not the counters of digital design. An RTL counter divides a clock, while a PMU counter observes behavior.

    Kind

    Counts

    Cost of using it

    Fixed-function

    Cycles, instructions, and a few common events

    Near zero: always available

    Programmable

    One selected event per counter

    One setup step per counter per run

    Per-core

    Events for one core

    Must be aggregated for chip claims

    System-wide

    Fabric, memory controller, or accelerator events

    Needs a synchronized window with core counts

    Related topics

    • Counters and timers (RTL design)

    Privilege, enable and overflow

    A counter increments only when every gate agrees: the counter is enabled, the privilege filter admits the current mode, and the event fires. Any disabled gate freezes the count.

    Each counter is N bits wide, so it wraps after 2^N events and raises an overflow indication. A 32-bit cycle counter on a 3 GHz core wraps every 2^32 / 3e9 seconds, about 1.4 seconds.

    Diagram
    overflow period = 2^32 cycles / 3.0e9 cycles/s
      = 4294967296 / 3000000000 s
      = 1.43 s  (about 1.4 s)

    Scope mistakes

    Per-core counts cannot answer system questions alone. A core that looks idle may be waiting on a saturated memory controller that only system counters can see.

    Common pitfall

    Fixed-function PMUs cannot fully separate every stall cause. Multiplexing, sampling skid, event aliasing, and undocumented event interactions limit attribution, so every claim needs a denominator and a consistency check.

    Interview

    Likely probes: why a count is trusted, and what each gate contributes.

    • Name the event, the denominator, the window, and the scope before quoting any number.

    • Privilege filters and enable windows explain most counts that look impossibly low.

    • Overflow period sets the longest run a wide counter can cover without wrapping.

    Check yourself A programmable counter reads far lower than expected while cycles look normal. Which gates do you check first?

    Enable, privilege filter, and event selection. The counter only moves when all three agree, so a closed gate explains a low count with normal cycles.

    Check yourself A 32-bit event counter wraps mid-run on a 3 GHz core counting cycles. Roughly how often must software drain it?

    About every 1.4 seconds. The calc block above shows 2^32 / 3e9 = 1.43 s, so drain well inside that bound.

    Testbench

    A small saturating PMU counter with enable, privilege gate, and sticky overflow, plus a testbench that proves each gate.

    pmc_counter.sv
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    module pmc_counter #(
      parameter int W = 4
    )(
      input  logic clk,
      input  logic rst_n,
      input  logic en,
      input  logic priv_ok,
      input  logic evt,
      output logic [W-1:0] count,
      output logic sticky
    );
      logic [W-1:0] cnt_q;
      logic sticky_q;
      assign count = cnt_q;
      assign sticky = sticky_q;
      always_ff @(posedge clk or negedge rst_n) begin
        if (!rst_n) begin
          cnt_q <= '0;
          sticky_q <= 1'b0;
        end else if (en && priv_ok && evt) begin
          if (cnt_q == {W{1'b1}}) begin
            cnt_q <= '0;
            sticky_q <= 1'b1;
          end else begin
            cnt_q <= cnt_q + 1'b1;
          end
        end
      end
    endmodule
    
    Previous

    49 / 86

    Next: CPI, IPC, MPKI and Derived Metrics

    Up next

    Up nextCPI, IPC, MPKI and Derived Metrics

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Multiplexing, Denominators and Trust
    • Top-Down Bottleneck Attribution
    • Freeze the Workload, One Experiment, Replay