跳转至

IPrefetchPipe Submodule Documentation

IPrefetchPipe is the pipeline for prefetching, designed as a two-stage pipeline, responsible for filtering prefetch requests.

IPrefetchPipe Structure

S0 Pipeline Stage

In the S0 pipeline stage, it receives prefetch requests from FTQ/backend and sends read requests to MetaArray and ITLB.

S1 Pipeline Stage

First, it receives the response from ITLB to get the paddr, then compares it with the tag returned by MetaArray to obtain hit information. It writes the metadata (hit information waymask, ITLB information paddr/af/pf) to WayLookup. Simultaneously, it performs a PMP check and registers the result to the next pipeline stage.

It is controlled by a state machine:

  • The initial state is idle. When a new request enters the S1 pipeline stage, it first checks if there is an ITLB miss. If it's a miss, it enters itlbResend; if ITLB hits but the hit information is not enqueued in WayLookup, it enters enqWay; if ITLB hits, WayLookup is enqueued, but the S2 request is not finished processing, it enters enterS2.
  • In the itlbResend state, it resends the read request to ITLB. At this point, it occupies the ITLB port (i.e., new prefetch requests entering the S0 pipeline stage are blocked) until the request backfill is complete. In the cycle when backfill is complete, it sends a read request to MetaArray again. During backfill, new writes may occur. If MetaArray is busy (being written by MSHR), it enters metaResend, otherwise it enters enqWay.
  • In the metaResend state, it resends the read request to MetaArray. After successfully sending, it enters enqWay.
  • In the enqWay state, it attempts to enqueue the metadata into WayLookup. If the WayLookup queue is full, it blocks until WayLookup is successfully enqueued. Additionally, enqueue is forbidden when new writes occur in the MSHR, primarily to prevent conflicts between the written information and the hit information, requiring an update to the hit information. When successfully enqueuing in WayLookup, if S2 is idle, it returns directly to idle, otherwise it enters enterS2.
  • If the current request is a software prefetch, it will not attempt to enqueue WayLookup because this request does not need to enter MainPipe/IFU or even be executed.
  • In the enterS2 state, it attempts to flow the request to the next pipeline stage. After flowing in, it returns to idle.

IPrefetchPipe S1 State Machine

S2 Pipeline Stage

Combining the request's hit result, ITLB exception, and PMP exception, it determines whether prefetching is necessary. Prefetching is only performed when no exceptions exist, because the same predicted block might correspond to two cachelines. Therefore, requests are sequentially sent to the MissUnit via an Arbiter.

Hit Information Update

After obtaining hit information in the S1 pipeline stage, there are two stages before the hit information is actually used in the MainPipe: the stage of waiting to be enqueued in IPrefetchPipe into WayLookup, and the stage of waiting to be dequeued from WayLookup. During the waiting period, updates to Meta/DataArray by MSHR may occur. Therefore, it is necessary to monitor the MSHR's response, which falls into two cases:

  1. The request missed in MetaArray, and it is monitored that MSHR wrote the cacheline corresponding to this request into SRAM. The hit information needs to be updated to a hit state.
  2. The request already hit in MetaArray, and it is monitored that writes of other cachelines occurred at the same location, overwriting the original data. The hit information needs to be updated to a miss state.

In order to prevent the delay of the update logic from being introduced into the DataArray access path, enqueue into WayLookup is forbidden when new writes occur in the MSHR, and it is enqueued in the next cycle.