Core concepts

From headline to useful bandwidth

For an AXI data channel accepting at most one beat per cycle, peak bandwidth in bytes/s is (data width in bits / 8) × clock frequency. Sustained useful bandwidth counts accepted useful bytes over elapsed time. Separate channels let AXI address and response activity overlap data transfers; do not subtract them as an automatic data-channel cycle tax. Packet protocols instead need their own encoding, framing and header accounting.

For a full-width AXI read, count bytes only at rising edges where RVALID && RREADY. A 64-byte burst on a 64-bit bus has eight beats. Four 16-byte bursts request the same payload through four addresses, which can increase request-side pressure, but the payload remains 64 bytes. For writes, count the WSTRB-enabled bytes on accepted W beats. Packet payload efficiency is useful payload bytes divided by transmitted bytes over a stated boundary.

AXI READ ACCOUNTING (illustrative, full-width beats)

64-bit data / 8 = 8 bytes per accepted beat
800 MHz clock  = 6.4 GB/s data-channel ceiling

1,000 measured cycles = 1.25 microseconds
750 accepted beats x 8 bytes = 6,000 useful bytes
6,000 bytes / 1.25 microseconds = 4.8 GB/s

Do not count stalled offers as additional transfers.
Address stalls may explain gaps; do not subtract them twice.

Latency vs throughput tradeoff

Burst length trades latency for efficiency. Short bursts: low latency per transaction, poor bus utilization. Long bursts: high efficiency, but one long burst blocks other masters (head-of-line blocking). Video DMA wants long bursts; interrupt status register reads want single-beat low latency.

Outstanding depth hides latency but increases reorder complexity and buffer area. The product question: which workload's latency tail matters? Interactive UI cares about p99 CPU read latency. Background encode cares about sustained GB/s.

• Report p50, p95, p99 latency — average hides tail pain.

• Burst length: tune per master class, not one global setting.

• QoS: separate latency-sensitive from bulk traffic queues.

The latency knee curve

Plot latency (y) against offered load (x) for one named workload and system configuration. At low load, latency can remain near the intrinsic round-trip. As offered work approaches the measured service capacity, queues build and latency rises; the curve's knee depends on burstiness, arbitration, buffer limits, traffic mix and the service-time distribution.

Choose a target below the measured knee with enough headroom for the workload's expected bursts and latency objective. There is no universal safe utilisation percentage: repeat the sweep at the relevant traffic mixes and operating corners, then record the load at which the required latency percentile first fails.

LATENCY vs OFFERED LOAD

latency
  ^                                    *
  |                                  *   <- collapse region
  |                               *
  |                          *  <- measured knee for this replay
  |                  *  *
  |   *  *  *  *
  +----------------------------------------> offered load
             low       target    knee

Design target: measured knee minus justified headroom.
Re-measure when workload, arbitration or service time changes.

Head-of-line blocking

One slow transaction at the head of a queue blocks all behind it, even if those could complete independently. Example: CPU read stuck behind a long DMA burst in a shared FIFO arbiter. Multiple queues, multiple IDs, and QoS preemption reduce HOL blocking but add design complexity.

DRAM row miss at the head of the memory scheduler queue stalls all pending requests to that bank — classic HOL at the memory subsystem.

• Separate read and write queues in memory controller.

• QoS preemption: pause bulk DMA when CPU read queue depth rises.

• Multiple outstanding IDs: responses can bypass blocked head (if protocol allows).

Common misconceptions

Doubling bus width doubles application performance.

Width alone does not determine the gain. If clock, accepted-beat fraction and useful bytes per lane remain unchanged, doubling width doubles payload bandwidth. If downstream capacity is fixed in bytes/s, that capacity can prevent a gain. A 50% stall statistic alone cannot predict the result; compare the same workload and all limiting path capacities.

Peak DRAM bandwidth from datasheet applies to all workloads.

Useful bandwidth depends on access pattern, request size, bank and row locality, controller policy, refresh, competing traffic and the measurement boundary. Measure the intended replay instead of applying a universal percentage of the headline rate.

Low average latency means good user experience.

p99 latency drives UI jank, frame drops, and tail SLAs. A system with 50ns average and 2ms p99 is worse than 100ns average with 200ns p99 for interactive workloads.

Key takeaways

• Report p50, p95, p99 latency — average hides tail pain.

• Burst length: tune per master class, not one global setting.

• QoS: separate latency-sensitive from bulk traffic queues.