Computer Architecture · All levels
QoS and Arbitration Policies — Worked Example
Worked Example for QoS and Arbitration Policies (NoC and Interconnect Architecture).
Scenario
A product workload exposes a QoS and Arbitration Policies issue late in architecture review.
Timeline
Metric fails at review meeting
Engineer captures metric report, trace snippet, and workload phase
Root cause traced to incorrect assumption from prior stage
Minimal architecture change or policy experiment applied and documented
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.
STAFF ARCHITECTURE REVIEW MEMO — NoC and Interconnect Architecture / QoS and Arbitration Policies
1. Current state
- Failing / watched metric: QoS service-level compliance 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: Unverified QoS policy can ship a nominally fast design that violates real-time contracts in field workloads.
4. Regression and signoff
- Re-run: QoS service-level compliance report
- Must not regress: DVFS policy stability, multimedia quality, and safety timing guarantees.
- Decision owner: System architectBefore / after metric graph
METRIC TREND GRAPH — QoS and Arbitration Policies
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.
Study notes
Re-read this topic with one concrete workload.