Data corruption or PLB bus hangs occur when a SPLB0 or SPLB1 slave PLB port and another PLB slave which supports address pipelining are connected to the same PLB bus. This also occurs when two PPC440 SPLB0/1 ports are connected to the same bus.
How do I resolve this issue?
This problem only occurs under an uncommon scenario for PLB bus usage. The plb_v46 arbiter supports only 2-deep address pipelining, so it broadcasts a single rdPrim and wrPrim signal to all slaves. The SPLB interface of the PPC440 hard-block was designed to work with arbiters supporting N-deep pipelining. If the PPC440 SPLB samples a rdPrim or wrPrim intended for a different slave (when there has not been an SAValid acknowledged by the SPLB), then the SPLB might be driving the bus out of turn. This can result in either a data corruption or a bus hang. This problem cannot occur if the bus has only one master that does not issue pipelined transactions, or if all other slaves on the bus do not support address pipelining (i.e., the other slaves do not assert addrAck in response to SAValid).
All other EDK cores, including custom PLBv46 slaves based on the EDK PLBv46 IPIF, do not support address pipelining and are not affected by this issue.
If more than one PPC440 SPLB is connected to the same bus, only one can perform pipelining; the others must have their 3 inputs disconnected.
You can disconnect (tie to ground) these signals using System Assembly GUI, Ports view, after enabling visibility of Default Connections in the Filters menu.