The method used in the AXI Crossbar core to avoid deadlock is “Single Slave per ID.” This method does not impact the performance of the transactions of most critical concern. These are the pipelining of multiple Reads and Writes, and by multiple master devices to a performance-critical slave device, such as a memory controller.
The “Single Slave per ID” method imposes the restriction that each ID thread received at each SI slot (from each master device) can have outstanding transactions (in each of the write and read directions) to only one MI slot at a time. However, MI slots are still permitted to issue multiple outstanding transactions originating from multiple SI slots.
By imposing this rule in the example shown in the previous section, the Read transaction from M0 to S1 in step 2 is stalled until S0 completes its response to M0. Similarly, the transaction from M1 to S0 in step 4 is stalled until S1 completes its response to M1. Whatever ways the transactions proceed forward under these conditions would avoid the interdependencies that could cause deadlock.
Besides preventing deadlock, the Single Slave per ID rule also guarantees in-order completion of all Write transactions at the SIs, even if different MI slots are targeted by a transaction thread in successive transactions. For example, a master device writes to a direct memory access (DMA) descriptor in memory, then writes (using the same AWID) to a control register in a DMA engine that subsequently reads that descriptor.
Because the AXI Crossbar core does not allow the second Write to propagate to the DMA slave device until the first Write completes (Write response received from the memory controller), there is no risk that the DMA reads stale descriptor data from memory. Each master device is therefore guaranteed in-order completion of transactions to various slave devices, in the same direction, and on the same ID thread. Therefore, under those conditions, master devices do not need to condition subsequent Write transactions on receiving Write responses for prior transactions.
IMPORTANT: AXI protocol provides no means to ensure in-order completion between Write and Read transactions other than waiting for the B-Channel responses of all earlier writes to complete.