Computer Architecture · All levels

Floorplan-Aware Architecture — Worked Example

Worked Example for Floorplan-Aware Architecture (SoC Architecture Tradeoffs).

Scenario

A product workload exposes a Floorplan-Aware Architecture issue late in architecture review.

Timeline

  1. Metric fails at review meeting

  2. Engineer captures metric report, trace snippet, and workload phase

  3. Root cause traced to incorrect assumption from prior stage

  4. Minimal architecture change or policy experiment applied and documented

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

diagram
STAFF ARCHITECTURE REVIEW MEMO — SoC Architecture Tradeoffs / Floorplan-Aware Architecture

1. Current state
   - Failing / watched metric: Architecture floorplan feasibility 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: Ignoring physical topology early creates timing walls and costly repartitioning late.

4. Regression and signoff
   - Re-run: Architecture floorplan feasibility report
   - Must not regress: Congestion, CTS quality, CDC robustness, and route-time predictability.
   - Decision owner: architecture owner

Before / after metric graph

diagram
METRIC TREND GRAPH — Floorplan-Aware Architecture

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.

Study notes

Re-read this topic with one concrete workload.