PPA at System Level — Pitfalls & Red Flags

Common mistakes

• Using one synthetic KPI to justify architecture shifts across all product modes.

• Setting block budgets without accounting for integration overhead and clock/power infrastructure.

• Treating verification complexity growth as free when adding speculative microarchitectural features.

Red flags in reviews

• Block owner cannot show margin history by release tag.

• Performance claims exclude realistic thermal or power-delivery constraints.

• Risk tracker contains many 'to be tuned in PD' items without owners.

Failure modes seen in real product programs

• A performance win is accepted on one benchmark while product workloads regress.

• A simulation result is trusted without matching PMU counter definitions.

• A microarchitecture knob hides a workload-specific issue but creates verification and PPA debt.

• A local improvement in PPA at System Level regresses Floorplan utilization, power-grid design, STA closure, and verification convergence..

How a senior engineer recovers

1. Freeze the evidence: workload, model/RTL tag, counter setup, trace, and simulator switches.

2. Name the real owner and approval path.

3. Convert the lesson into a checklist item, regression, or methodology guardrail.

Pitfall map

TRADEOFF MATRIX — PPA at System Level

+----------------------+----------------------+----------------------+----------------------+
| Option               | Helps                | Can hurt             | Validation needed    |
+----------------------+----------------------+----------------------+----------------------+
| Larger / wider block | peak perf, miss rate | area, power, timing  | workload sweep       |
| Smarter policy       | hit rate, QoS, IPC   | verification risk    | corner cases + PMU   |
| More buffering       | latency tails, stalls| deadlock, leakage    | stress traffic tests |
| Software contract    | locality, ordering   | portability, APIs    | production workload  |
+----------------------+----------------------+----------------------+----------------------+

Senior rule: pick the smallest change that proves or disproves the mechanism.

Architecture 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.