DenseChip

Computer Architecture · All levels

Performance Counters and Telemetry

Performance Counters and Telemetry — computer architecture for silicon teams.

On-call / interview prompt

Your IPC dropped 14% on silicon versus pre-silicon projections. Which counters do you trust first and why?

diagram
ARCHITECTURE ANALYSIS CHAIN

1. METRIC     — IPC, CPI, MPKI, bandwidth, latency, queue depth, stall cycles
2. HYPOTHESIS — microarch or system cause ordered by likelihood
3. EXPERIMENT — trace, PMU counter, simulation, or RTL probe
4. CHANGE      — pipeline, cache, NoC, or memory hierarchy adjustment
5. VALIDATION  — workload replay, regression suite, PPA impact

Topic overview

Design and validate a counter strategy that maps workload intent to actionable microarchitectural evidence.

Mechanism to narrate

  • Section: Performance Analysis

  • Primary artifact: Counter integrity and stall attribution dashboard

  • Downstream dependency: RTL changes, compiler strategy, firmware scheduler tuning, and KPI commitments.

Staff/principal ownership model

Own Performance Counters and Telemetry as a product architecture decision, not a page of notes. A senior architect names the metric, the mechanism, the cross-team dependency, and the smallest evidence-producing experiment.

diagram
STAFF ARCHITECTURE REVIEW MEMO — Performance Analysis / Performance Counters and Telemetry

1. Current state
   - Failing / watched metric: Counter integrity and stall attribution dashboard
   - Workload / benchmark / trace: <fill before review>
   - Model tag, RTL tag, simulator version, PMU setup: <fill before review>
   - Scope: core, cache level, NoC path, coherency domain, accelerator, or SoC budget

2. Root-cause hypothesis
   - Most likely mechanism: <name pipeline/cache/NoC/coherency/perf mechanism>
   - Competing hypothesis: <name the second plausible cause>
   - Evidence still missing: <counter, trace, waveform, model sweep, or workload slice>

3. Proposed action
   - Minimal reversible change: <microarchitecture, policy, sizing, traffic, or software contract change>
   - Expected improvement: <metric delta>
   - Regression risk: Bad counter trust can send teams toward expensive but irrelevant optimizations.

4. Regression and signoff
   - Re-run: Counter integrity and stall attribution dashboard
   - Must not regress: RTL changes, compiler strategy, firmware scheduler tuning, and KPI commitments.
   - Decision owner: architecture owner

Sub-lessons in this topic

  1. mechanism — Mechanism

  2. inputs-outputs — Inputs & Outputs

  3. reports — Reports & Metrics

  4. debug-playbook — Debug Playbook

  5. worked-example — Worked Example

  6. pitfalls — Pitfalls & Red Flags

  7. interview — Interview Drills

  8. checklist — Review Checklist

  9. theory-deep-dive — Theory Deep Dive

  10. design-space — Design Space Exploration

  11. case-study-expanded — Extended Case Study

  12. step-by-step-walkthrough — Step-by-Step Walkthrough

  13. comparison-matrix — Comparison Matrix

  14. software-programmer-view — Software / Programmer View

  15. silicon-ppa-impact — Silicon & PPA Impact

Related topics

Key takeaways

  • Master Performance Counters and Telemetry through workload metrics, not feature lists.

Architecture deep dive

PMU evidence beats intuition for architecture decisions.

Concept diagram

diagram
TOP-DOWN PERFORMANCE METHOD

Total cycles
 ├─ Retiring useful work
 ├─ Frontend bound
 ├─ Bad speculation
 ├─ Backend core bound
 └─ Backend memory bound

Only after classification should you propose cache, branch, pipeline, or NoC changes.

Metric graph

diagram
ROOFLINE SKETCH

Performance
  ^
  |                     compute roof
  |-------------------------------
  |                   /
  |                 /
  |               /   ● workload A (compute-bound)
  |             /
  |   ● workload B (memory-bound)
  +---------------------------------> arithmetic intensity
        memory bandwidth slope

Metrics and artifacts

  • PMU event sets

  • roofline chart

  • top-down stall breakdown

  • workload sensitivity matrix

Mini case study

Team proposed wider SIMD but roofline showed memory-bound kernel — bandwidth upgrade and locality fix delivered 2× speedup at lower area cost.

Debug branches

  • If counters disagree with sim, align workload and warmup.

  • If bottleneck unclear, use top-down method before microarch tweaks.

Senior review question

Ask: what single metric would prove this concept is working or failing on your workload?

Key takeaways

  • Connect every architecture claim to a workload and measurable metric.

  • State verification and PPA impact before proposing design changes.

Common pitfalls

  • Feature-driven design without MPKI/IPC/bandwidth evidence.

  • Ignoring coherency and NoC traffic in cache and accelerator sizing.

Practice this lesson