The following example shows how a sequence of Read transactions can result in deadlock. A similar situation also applies to a sequence of Write transactions when a slave device can reorder its Write response. This example shows a case where there are two master devices (M0 and M1) and two slave devices (S0 and S1) connected using the SmartConnect core. This example assumes IDs are propagated to slaves supporting response reordering.
1.Master device M0 reads from Slave device S0.
2.Master device M0 then reads from Slave device S1 (using the same ID thread).
3.Master device M1 then reads from Slave device S1.
4.Master device M1 then reads from Slave device S0 (using the same ID thread).
5.Slave device S0 responds to Master device M1 first. It reorders the Read response, which is allowable because the transaction IDs received on transactions from different masters are different. However, the SmartConnect core must not pass the response to Master device M1 because Master device M1 must first receive its response from Slave device S1.
6.Slave device S1 responds to Master device M0 (it does not reorder). But the SmartConnect must not pass the response to Master device M0 because Master device M0 must first receive its response from Slave device S0.
This results in deadlock.