A PCIe device writes DMA data into SoC memory and then sends an MSI. On the PCIe side, the MSI cannot pass the data (lesson 7.9). Inside the SoC, a bridge turns each PCIe write into an AXI write, and, for throughput, spreads them across several AXI IDs. The MSI write gets its own ID. On AXI, different IDs carry no ordering, and the MSI reaches the interrupt controller before the last data write reaches memory. Each protocol's rules were followed. The bridge dropped the guarantee in between.
How does a bridge keep the ordering guarantees of both protocols it joins?
The obvious bridge translates each transaction and forwards it as soon as it can. That preserves meaning (a write is a write) but not ordering: each protocol describes ordering differently (posted/non-posted rules, per-ID order, fences), and a guarantee expressed in one vocabulary has no automatic equivalent in the other. A bridge must actively re-create, on the far side, every ordering promise the near side made.
Source-side promise | Ways to keep it on an ID-ordered side (AXI) | Cost |
|---|---|---|
Posted writes stay in order | Issue them on one ID; or issue a later write only after earlier writes' responses (from the destination) have returned | Less parallelism, or a round trip at each ordering point |
A read may not pass earlier writes | Hold the read until the earlier writes' responses have returned | Read latency after writes |
Completions may not pass earlier posted writes | Return read data to the PCIe side only after earlier writes in that direction are complete | Completion latency |
Relaxed-ordering writes may pass | Spread them across IDs freely | None: this is where the bridge regains throughput |
Going the other way, from an ID-ordered protocol onto a posted/non-posted one, the risk is the opposite: the far side may impose more order than the near side needs (harmless but slow), or a write response that the near side expects to mean "arrived" may be generated by the bridge before the posted write has gone anywhere (lesson 7.4).
List every ordering rule of each side (passing table, per-ID order, fences, read-write ordering).
For each rule of the source side, name the mechanism that enforces it on the far side: one ID, one queue, waiting for responses, a fence.
Check write responses: what does a response from the bridge promise, and does that match what the source side's response means?
Check that the bridge never adds relaxation (marks traffic relaxed, spreads strictly ordered writes across IDs) that the source did not ask for.
Test with producer/consumer traffic (data then flag, data then MSI) crossing the bridge under heavy load.
Bridge | Typical ordering approach |
|---|---|
PCIe to AXI (inbound to SoC memory) | Strictly ordered posted writes on a single AXI ID or ordered queue; relaxed-ordering writes may be spread across IDs; MSIs ordered behind earlier writes. |
AXI to PCIe (outbound) | AXI writes become posted PCIe writes; the bridge must decide when to send the AXI write response, and keeps per-ID AXI order within PCIe's stricter posted order. |
The opening bridge (illustrative) spread every inbound posted write across four AXI IDs to use four memory paths, ignoring whether the write was marked relaxed. Bulk data got faster; MSIs and completion-queue entries occasionally overtook the data they announced. Respecting the Relaxed Ordering bit, spreading only relaxed writes and keeping strict ones on one ID, kept most of the speed and all of the correctness.
Yes, same-ID writes stay in order on AXI, but all inbound writes are serialised on one ID, losing parallelism across memory paths.
The requester declared they need no ordering among themselves, so different IDs (no ordering) honour that; strict writes behind them must still not pass them.
A bridge must re-create on the far side every ordering promise the source side made.
Posted-write order maps to one ID, one queue, or waiting for responses; relaxed traffic may be spread.
Specify the mapping rule by rule and test producer/consumer traffic across the bridge under load.