Computer Architecture · All levels
PPA at System Level — Worked Example
Worked Example for PPA at System Level (SoC Architecture Tradeoffs).
Scenario
A product workload exposes a PPA at System Level issue late in architecture review.
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
Architecture decision accepted with documented metric movement, risk, and validation proof.
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.
STAFF ARCHITECTURE REVIEW MEMO — SoC Architecture Tradeoffs / PPA at System Level
1. Current state
- Failing / watched metric: System-level PPA budget ledger
- 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: Weak budget governance causes late-stage PPA churn and cross-team blame loops.
4. Regression and signoff
- Re-run: System-level PPA budget ledger
- Must not regress: Floorplan utilization, power-grid design, STA closure, and verification convergence.
- Decision owner: architecture ownerBefore / after metric graph
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 movedArchitecture deep dive
Chip architecture signoff is a negotiated PPA contract across teams.
Concept 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
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.
Study notes
Re-read this topic with one concrete workload.