2.3. Speculative fetch

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 is issued before all hazards that had arisen from the corresponding snoop have been resolved. Therefore, it is sometimes necessary to discard the data returned from memory and retry the fetch. These cases are:

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

Note

Speculative fetches are only issued for these read-type transactions:

  • ReadOnce.

  • ReadClean.

  • ReadNotSharedDirty.

  • ReadUnique.

  • 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, you can disable speculative fetches where you expect a significant number of snoops to hit. You can use the Speculation Control Register to disable speculative fetches for a master or a slave interface. For example, you can disable speculative fetches for transactions from a master that is not latency sensitive. See Speculation Control Register.

Copyright © 2011-2013 ARM. All rights reserved.ARM DDI 0470I
Non-ConfidentialID091313