Reconstruct acceptance, ordering and useful throughput before proposing a faster interface.
Try these before opening the explanations. This is a self-assessment, not a stored score or certification.
Three beats, 24 bytes over 60 ns: 400 MB/s, or 0.4 decimal GB/s. Stalled offers do not add bytes. This interval rate is not the bus's eight-byte × 100 MHz = 0.8 GB/s ceiling.
ID 7 may complete independently under the stated ordinary AXI4 ordering rules. ID 3 still selects the oldest pending request A. Neither the response data nor a later request's address permits searching past that head.
Ready to continue when you can produce:
A sampled acceptance table with offered versus accepted work.
The live per-ID queue state and a boundary/units-labelled rate calculation.
A destination may wait to observe VALID before becoming ready. If the source also waits, both can remain low with an item pending. This waiting deadlock does not require a combinational loop. Retain VALID and its payload until acceptance, and separately obey AXI's no-combinational-input-to-output timing rule.
Common trap: Confusing a waiting dependency with a literal combinational loop.
A width-and-rate product is a transfer-capacity ceiling at a stated boundary. Payload efficiency is useful payload divided by total transmitted bytes over another explicitly stated boundary. Accepted useful bytes over elapsed time additionally includes idle/service gaps; keep these three quantities separate.
Common trap: Quoting peak GB/s or an efficiency percentage without a boundary and byte definition.
When the protocol allows reorder across IDs; same-ID ordering rules still apply.
Common trap: Claiming all buses are strictly ordered.
Start with the transaction identity/correlation key and the smallest logs, counters or waveform window that show its last confirmed progress and expected next event. The exact first artifact depends on which boundaries are observable.
Common trap: Increasing timeout before locating the request and its last state transition.
That evidence is insufficient to name a layer. Define what the waveform captured and which rules were checked, then correlate the software operation with address, width, attributes, ordering, translation, response and relevant reset/power/link state across each boundary.
Common trap: Treating a finite clean capture as proof of end-to-end correctness.
Bound occupancy as initial occupancy plus accepted writes minus completed reads. Include burst timing, guaranteed service, consumer pauses and all extra items accepted before a stop takes effect. Pointer/flag synchronisation affects that timing budget, not a universal fixed number of data slots. No finite FIFO handles an indefinitely faster source unless it can be throttled.
Common trap: Multiplying burst length by a clock ratio without modelling arrivals, departures and stop latency.
A slow or stalled transaction at the front of a queue blocks all transactions behind it, even if those could complete independently. Outstanding depth and multiple IDs/queues reduce but don't eliminate it.
Common trap: Confusing with backpressure on a single valid/ready channel.
A shared correlation key prevents teams from comparing different operations. An ID may be absent, reused or remapped, so combine the fields available at each boundary—such as source port, ID/tag, address/range, byte offset and time—and record the bridge mapping.
Common trap: Assuming one numeric ID survives unchanged, or using address alone with multiple outstanding operations.