Computer Architecture · All levels
Routing and Flow Control — Reports & Metrics
Reports & Metrics for Routing and Flow Control (NoC and Interconnect Architecture).
On-call / interview prompt
Where does the first sustained queue build-up occur, and is it caused by path choice or credit starvation?
ARCHITECTURE ANALYSIS CHAIN
1. METRIC — IPC, CPI, MPKI, bandwidth, latency, queue depth, stall cycles
2. HYPOTHESIS — microarch or system cause ordered by likelihood
3. EXPERIMENT — trace, PMU counter, simulation, or RTL probe
4. CHANGE — pipeline, cache, NoC, or memory hierarchy adjustment
5. VALIDATION — workload replay, regression suite, PPA impactReports to inspect
Virtual-channel occupancy histogram
Credit round-trip latency profile
Head-of-line blocking incidence report
FLOW CONTROL HEALTH
traffic_profile: mixed_cpu_dma_io
aggregate_offered_load: 0.72
achieved_throughput: 0.61
p99_latency_cycles: 143
vc0_hol_block_events: 382
credit_return_p95_cycles: 21
deadlock_watchdog_events: 0
likely_bottleneck: vc_partitioning_vs_credit_depthSmoke check (5 minutes)
Can you name the single worst line in the report?
Can you tie that line to a workload phase, structure, master, or data movement pattern?
How to read this like an architecture lead
The report is not a pass/fail artifact; it is a prioritization tool. Read Routing/flow-control stress verification report by severity, locality, trend, and fix cost before touching the design.
Report triage order
Confirm workload, model tag, seed, counter definitions, and warmup window.
Separate product blockers from exploratory tuning opportunities.
Cluster failures by workload phase, master, cache level, NoC path, coherency state, or accelerator kernel.
Compare against previous tag to identify new regressions, not just absolute failures.
Translate the worst line into an owner, experiment, and rollback plan.
SENIOR REPORT READOUT
worst_line: <copy exact report line>
cluster: <workload phase / master / cache level / NoC path / coherency state>
delta_from_previous: <new/worse/better/same>
first_experiment: <cheap evidence-gathering action>
decision: <change design / assign owner / keep risk with approval / stop release>Metric graph to sketch in review
REPORT GRAPH — Routing/flow-control stress verification report
stall contribution (% cycles)
frontend ████████████ 24
backend ██████████████████ 36
memory ████████████████████████ 48
fabric/qos ████████ 16
coherency ██████████ 20
How to read:
1. Identify the dominant bar, not the noisiest anecdote.
2. Cross-check with at least one independent artifact: trace, PMU, sim log, or waveform.
3. If the dominant bar does not match the proposed fix, stop and reform the hypothesis.Trend graph
METRIC TREND GRAPH — Routing and Flow Control
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
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.