Computer Architecture · All levels

Roofline Thinking for SoC Tradeoffs — Worked Example

Worked Example for Roofline Thinking for SoC Tradeoffs (Performance Analysis).

Scenario

Vision pipeline appears compute-limited at block-level tests but system traces show DRAM contention shifting it to bandwidth-limited in production.

Timeline

Metric fails at review meeting
Engineer captures metric report, trace snippet, and workload phase
Root cause traced to incorrect assumption from prior stage
Minimal architecture change or policy experiment applied and documented
Workload regression matrix re-run on the tagged model

Outcome

On-chip tiling and prefetch control move kernels closer to compute roof without widening execution units.

Senior debrief

After solving the example, write the debrief a lead would expect: what changed, why it worked, what could regress, and what permanent methodology update prevents recurrence.

diagram

STAFF ARCHITECTURE REVIEW MEMO — Performance Analysis / Roofline Thinking for SoC Tradeoffs

1. Current state
   - Failing / watched metric: Workload roofline placement report
   - 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: Incorrect roofline assumptions lead to costly area/power additions with weak KPI impact.

4. Regression and signoff
   - Re-run: Workload roofline placement report
   - Must not regress: Area-power-performance budgeting and accelerator roadmap choices.
   - Decision owner: architecture owner

Before / after metric graph

diagram

METRIC TREND GRAPH — Roofline Thinking for SoC Tradeoffs

IPC / throughput
  ^
  |                  target
  |                 ─ ─ ─ ─ ─ ─ ─
  |            ● after bounded fix
  |         /
  |    ● baseline
  |  /
  |● failing run
  +---------------------------------> experiment index
    bad tag       hypothesis        accepted fix

Readout rule:
  - one dot is not a conclusion
  - compare against same workload, seed, model tag, and counter setup
  - explain why the fix moved the metric, not just that it moved

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.

Study notes

Re-read this topic with one concrete workload.

Practice this lesson