Computer Architecture · All levels

PPA at System Level — Reports & Metrics

Reports & Metrics for PPA at System Level (SoC Architecture Tradeoffs).

On-call / interview prompt

Which report lines prove PPA at System Level is healthy vs failing?

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

Reports to inspect

Workload-weighted performance model report
Block-level area and power budget ledger
Mode/corner timing margin summary
Cross-domain risk burndown dashboard

diagram

SOC PPA LEDGER
  release: arch_r3
  perf_target_geomean: 1.18x
  power_budget_total_mw: 4200
  area_budget_total_mm2: 146
  timing_guardband_ps: 80
  unresolved_high_risks: 3

Smoke check (5 minutes)

Can you name the single worst line in the report?
Can you tie that line to a workload phase, structure, master, or data movement pattern?

How to read this like an architecture lead

The report is not a pass/fail artifact; it is a prioritization tool. Read System-level PPA budget ledger by severity, locality, trend, and fix cost before touching the design.

Report triage order

Confirm workload, model tag, seed, counter definitions, and warmup window.
Separate product blockers from exploratory tuning opportunities.
Cluster failures by workload phase, master, cache level, NoC path, coherency state, or accelerator kernel.
Compare against previous tag to identify new regressions, not just absolute failures.
Translate the worst line into an owner, experiment, and rollback plan.

diagram

SENIOR REPORT READOUT
  worst_line: <copy exact report line>
  cluster: <workload phase / master / cache level / NoC path / coherency state>
  delta_from_previous: <new/worse/better/same>
  first_experiment: <cheap evidence-gathering action>
  decision: <change design / assign owner / keep risk with approval / stop release>

Metric graph to sketch in review

diagram

REPORT GRAPH — System-level PPA budget ledger

stall contribution (% cycles)

frontend      ████████████  24
backend       ██████████████████  36
memory        ████████████████████████  48
fabric/qos    ████████  16
coherency     ██████████  20

How to read:
  1. Identify the dominant bar, not the noisiest anecdote.
  2. Cross-check with at least one independent artifact: trace, PMU, sim log, or waveform.
  3. If the dominant bar does not match the proposed fix, stop and reform the hypothesis.

Trend graph

diagram

METRIC TREND GRAPH — PPA at System Level

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

Chip architecture signoff is a negotiated PPA contract across teams.

Concept diagram

diagram

PPA NEGOTIATION MAP

Architecture target
   │
   ├─ Performance: IPC, latency, bandwidth, QoS
   ├─ Power: dynamic, leakage, thermal envelope
   ├─ Area: SRAM, logic, NoC links, floorplan
   ├─ Verification: state space, tests, formal complexity
   └─ PD: timing, placement, macro distance, routing channels

A staff architect makes the trade visible before it becomes a crisis.

Metric graph

diagram

PPA OPTION CHART

Option          Perf      Power     Area      Risk
A wider core    +++       ---       --        high
B better cache  ++        -         --        med
C SW locality   +         +         0         med
D NoC QoS       +         -         -         low

Pick based on product objective, not elegance.

Metrics and artifacts

PPA dashboard
floorplan distance budget
NoC BW matrix
verification closure status

Mini case study

CPU–memory macro distance violated latency budget — architecture accepted lower CPU frequency rather than respin floorplan one week before tapeout.

Debug branches

If PD pushes back, bring numeric latency/power models not opinions.
If signoff yellow, document owner, mitigation, and decision date.

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.

Read the numbers

Practice this lesson