NoC Topology Tradeoffs — Review Checklist

Review gate

1. Communication matrix validated with software and system teams.

2. Topology recommendation includes saturation and growth analysis.

3. Physical wiring and timing assumptions documented.

4. Fallback migration path exists if traffic mix shifts late.

Smoke check (5 minutes)

• Every checklist item has an owner

• Failed items have owner, mitigation, and decision record

Definition of done for a senior owner

1. The exact workload, model/RTL tag, counter setup, and analysis window are recorded.

2. The primary metric is clean, improved, or accepted as a documented product tradeoff: NoC topology comparison dashboard.

3. The change is explained by mechanism, not by architecture folklore.

4. Regression coverage includes the obvious downstream domains: QoS stability, coherency latency, and memory controller efficiency..

5. Residual risk has an owner, approval path, and expiration date.

6. The lesson is captured as a methodology guardrail if it can recur.

Smoke check (5 minutes)

• Could another engineer reproduce the conclusion from the notes alone?

• Would you sign this off if the design came from another team?

Review visual

TRADEOFF MATRIX — NoC Topology Tradeoffs

+----------------------+----------------------+----------------------+----------------------+
| 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

NoC is a queueing system — bandwidth, latency, and deadlock are coupled.

Concept diagram

NoC TOPOLOGY SKETCH

CPU0 ──┐      ┌── LLC0 ── DRAM0
       R0 ─── R1
CPU1 ──┘      │
              R2 ─── R3 ── GPU/DMA
              │      │
             NPU    LLC1 ── DRAM1

Look for: hot links, cyclic dependencies, VC starvation, and tail latency.

Metric graph

LATENCY DISTRIBUTION

p50    ██████  32 ns
p90    ████████████  71 ns
p99    ████████████████████████  210 ns
p99.9  █████████████████████████████████  480 ns

Averages hide QoS failures.

Metrics and artifacts

• link utilization

• average latency by master

• retry/backpressure counts

• QoS violation log

Mini case study

Average latency looks fine but tail latency spikes for CPU coherent reads when GPU DMA runs. QoS and separate VCs fix the starvation without doubling link width.

Debug branches

• If deadlock, check credit loops and routing restrictions first.

• If latency tail long, inspect arbitration and buffer depth.

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.