DenseChip

RISC-V Design ยท All levels

Pipeline Performance and CPI Decomposition: Debug Playbook

Debug Playbook for Pipeline Performance and CPI Decomposition.

Debug playbook

Debug Playbook for Pipeline Performance and CPI Decomposition is anchored on Measured CPI broken into ideal base CPI, structural stalls, data stalls, control stalls, and memory wait contributions.. Convert observations into mechanism-backed decisions with explicit ownership.

  1. Freeze workload seed, binary, compiler, firmware, and platform setup.

  2. Find earliest persistent mechanism failure in the timeline.

  3. Build one reduced reproducer for dominant hypothesis.

  4. Patch minimal fix with explicit rollback gate.

  5. Rerun correctness + performance + power matrix.

Decision tree

diagram
ROOT CAUSE TREE - Pipeline Performance and CPI Decomposition

Measured CPI broken into ideal base CPI, structural stalls, data stalls, control stalls, and memory wait contributions. regressed
          |
   reproducible on fixed seed?
      /                 \
    no                   yes
    |                     |
env/tool drift       first failing domain?
                     /        |         \
                  decode    execute    memory/MMU
                    |         |            |
               control map  bypass/FU   TLB/walk/perm
                    |
         privilege/CSR side effects checked?

Stop at first confirmed mechanism, then assign explicit owner + fix proof.

Review memo template

diagram
RISC-V REVIEW MEMO - Pipeline Implementation / Pipeline Performance and CPI Decomposition

1. Symptom
   - Failing metric: Measured CPI broken into ideal base CPI, structural stalls, data stalls, control stalls, and memory wait contributions.
   - Failing workload slice: <name>
   - Triggering mode: <privilege/virtualization/interrupt/cache/boot>
   - Build and runtime tags: <toolchain/firmware/RTL revision>

2. Mechanism hypothesis
   - Primary mechanism: Pipeline tuning is guided by CPI decomposition rather than aggregate throughput alone. Starting from ideal CPI near 1 for scalar in-order issue, engineers attribute extra cycles to specific causes: load-use interlocks, branch redirect penalties, cache miss latency, and occasional structural conflicts. Hardware performance counters should classify stall reasons at stage boundaries so software traces can map workload behavior to microarchitectural bottlenecks. This evidence then drives targeted changes such as adding bypass paths, moving branch resolve earlier, tuning cache hit latency, or simplifying decode critical paths that force lower frequency. Good closure practice reports both CPI and frequency impact because a change that lowers stalls but degrades clock can lose net performance.
   - Competing hypotheses: <decode control / hazard / MMU / privilege / integration>
   - Missing evidence: <trace/counter/proof/report>

3. Proposed action
   - Smallest reversible change: <RTL/compiler/runtime/config>
   - Expected movement: <throughput/latency/tail/perf-per-watt>
   - Regression risk: correctness, security, power, timing, software compatibility

4. Signoff
   - Required artifact: CPI accounting workbook and counter-instrumentation plan with benchmark-by-benchmark bottleneck attribution.
   - Required owners: performance modeling owner, CPU microarchitecture lead, compiler and toolchain liaison, verification lead, silicon validation owner
   - Final decision: ship, bounded rollout, rollback, or escalate
Practice this lesson