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.
Account for bytes at the accepted read-data boundary
Illustrative full-width AXI read channel: 64 bits, 800 MHz, 1,000 measured cycles and 750 accepted beats. GB/s uses decimal bytes.
Quantity | Calculation | Result |
|---|---|---|
Bytes per accepted beat | 64 / 8 | 8 bytes |
Transfer-capacity ceiling | 8 × 800,000,000 | 6.4 GB/s |
Elapsed observation time | 1,000 / 800,000,000 | 1.25 µs |
Accepted useful data | 750 × 8 | 6,000 bytes |
Measured useful throughput | 6,000 bytes / 1.25 µs | 4.8 GB/s |
What to notice
Only accepted beats contribute bytes; stalled presentations do not multiply payload.
Address-side pressure may explain data gaps, but must not be subtracted again from an already measured accepted-byte rate.
No. The given accepted count is 750. Using offers instead of accepted beats would falsely report the 6.4 GB/s ceiling.
Burst shape affects request pressure, service opportunities and latency, but the trade-off depends on the interface and scheduler. AXI address activity is not an automatic data-cycle tax. A long burst can occupy a shared service resource; whether unrelated work can proceed depends on permitted interleaving, queues and arbitration. Choose supported shapes from actual endpoint semantics and measured service goals.
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.
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.
What to notice
A curve belongs to its workload, service policy and measurement boundary.
Use the required percentile and burst conditions, not only average throughput, when choosing headroom.
No. The latency-objective failure and headroom come from the measured workload and conditions, which must be repeated when relevant inputs change.
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.
Arbitrate at supported service boundaries; do not invent mid-burst write interleaving or withdraw an accepted transfer to favour another class.
Multiple outstanding IDs: responses can bypass blocked head (if protocol allows).
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.
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.
Averages can hide an important slow population. In an illustrative 100-request replay, 98 requests take 50 ns and two take 2 ms. The mean is 40,049 ns (about 40 µs), and nearest-rank p99 is 2 ms. A constant 100 ns replay has both mean and p99 of 100 ns. Compare the same request population and percentile definition; a claimed 50 ns mean with 2 ms p99 would contradict this nonnegative sample set.