Avoiding Deadlock Using Single Slave Per ID - 1.0 English

SmartConnect (PG247)

Document ID
Release Date
1.0 English

The SmartConnect uses the Single Slave per ID method to avoid deadlock. This method does not impact the performance of the transactions of most critical concern. These are the pipelining of multiple Reads and Writes by multiple master devices, to a shared 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 (from each master device) can have outstanding transactions (in each of the write and read directions) to only one MI at a time. However, each MI is still permitted to issue multiple outstanding transactions originating from multiple SIs.

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. However the transactions proceed, under these conditions, interdependencies that could cause deadlock are avoided.

As well as preventing deadlock, the Single Slave per ID rule also guarantees in order completion of all Write transactions at the SIs, even if different MIs 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 thread-ID) to a control register in a DMA engine which subsequently reads that descriptor. Because SmartConnect 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 method of ensuring in order completion between Write and Read transactions, other than waiting for the B-Channel responses of all earlier writes to complete.