Routing and Flow Control — Pitfalls & Red Flags

Common mistakes

• Optimizing without naming workload, metric, and model setup

• Local fix that regresses neighboring metrics

• Skipping documented checklist before architecture review

Red flags in reviews

• Cannot explain worst report line

• No regression list after proposed fix

• Waiver requested without cluster analysis

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 Routing and Flow Control regresses QoS guarantees, coherency response latency, and software-visible jitter..

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 — Routing and Flow Control

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