2.3. Speculative fetches

For an application where the probability of a miss is high, then the snoop request and response time adds directly to the latency for each transaction labelled as shareable. To mitigate this, you can program each master interface to issue a fetch downstream in parallel with issuing a snoop request. This is known as a speculative fetch.

In the event that the snoop associated with a speculative fetch hits in a cache, then the data from the snoop is returned in preference to the data from the speculative fetch.

A speculative fetch bypasses the PoS, and therefore, might be made invalid by a transaction that should have been ordered before it. If a hazardous transaction is detected, or the data is returned before the snoop response is received, then the data from the speculative fetch is discarded and the request retried when the snoop response is received.

You can use the PMU to record the number of retry transactions for each master interface. See Performance Monitoring Unit (PMU).

Note

Speculative fetches are only issued for read-type transactions, that is, ReadOnce, ReadClean, ReadNotSharedDirty, ReadUnique, and ReadShared.

Although speculative fetches reduce the latency in the case of a snoop miss, there is a bandwidth and power penalty because of the additional transactions on a snoop hit. Therefore, only enable speculative fetches where you expect most snoops to miss. You can use the Speculation Control Register to disable speculative fetches. See Speculation Control Register.

Copyright © 2011-2012 ARM. All rights reserved.ARM DDI 0470D
Non-ConfidentialID040512