跳转至

Miss Queue

Function Description

Responsible for handling miss load, store, and atomic requests, containing 16 Miss Entries. Each entry is responsible for one request, and its processing flow is controlled by a set of state registers.

  • Miss load requests: MissQueue allocates an empty MissEntry for it and can merge or reject requests under certain conditions. After allocation, relevant information is recorded in the MissEntry. Requests entering the MissQueue send an Acquire request to L2. If it's an overwrite write for the entire block, AcquirePerm is sent (L2 will save one SRAM read operation); otherwise, AcquireBlock is sent. It waits for L2 to return permission (Grant) or data plus permission (GrantData) and returns GrantAck to L2 after receiving the first beat of Grant / GrantData. Before receiving the result returned by L2, it will receive a hint signal sent upwards by L2 in advance, indicating that the corresponding permission and data will arrive on the TileLink D channel 2 cycles later. After receiving the hint, MissQueue will initiate a refill request to MainPipe. Subsequently, after receiving Grant / GrantData, it will send the refill data into MainPipe through forwarding and wait for an acknowledgment. After completing the refill, the corresponding MissEntry is released.

  • Miss store requests: The process is basically the same as loads. After the refill is finally completed, MainPipe returns an acknowledgment to the StoreBuffer, indicating that the store is complete.

  • Miss atomic instructions: The process is basically the same as loads. After the refill is finally completed, MainPipe returns an acknowledgment to the AtomicsUnit, indicating that the atomic instruction operation is complete.

Feature 1: MissQueue Enqueue Processing

For new enqueued requests, the overall operations in MissQueue can be divided into response and rejection. Response can be further divided into allocation and merging. MissQueue supports a certain degree of request merging, thereby improving the efficiency of miss request processing.

  • Empty entry allocation: If a new miss request does not meet the merge or reject conditions, a new MissEntry is allocated for the request.

  • Request merge conditions: When the block address of an allocated MissEntry (request A) is the same as that of a new miss request B, request B can be merged under the following two conditions:

    • The Acquire request to L2 has not yet handshaked, and A is a load request, and B is a load or store request. That is, B can be merged before A successfully initiates a read request to L2, and they send Acquire together;
    • The Acquire to L2 has already been sent out, but Grant/GrantData has not yet been received, and A is a load or store request, and B is a load request. That is, new incoming load requests can be merged before refill, while store requests can only be merged before the acquire handshake.

  • Request reject conditions: In the following cases, the new miss request needs to be rejected. This request will be reissued after a certain period of time:

    • The block address of the new miss request is the same as that of a request in a certain MissEntry, but it does not meet the request merge conditions;
    • The Miss Queue is full.

Feature 2: MSHR Data Forwarding to LoadUnit

MissQueue supports data forwarding. If the LSQ re-issue signal is valid (for specific re-issue logic, please refer to the LoadQueueReplay section, which selects the most suitable oldest instruction), in LoadUnit's stage 1, the specified MSHR ID and address are forwarded. After MissQueue receives the forwarding information, it performs a comparison. If matched, the refilled data is directly transmitted to LoadUnit in LoadUnits' stage 2. This method obtains data from previous requests faster through forwarding, reducing the waiting time for load instructions.

Feature 3: MissQueue Prefetch Processing

For prefetch requests entering MissQueue, the source of the prefetch request is marked within the MissEntry. Other operations are the same as a regular load instruction, sending an Acquire request to L2 and waiting to receive Grant/GrantData to complete the refill.

Feature 4: Refill Requests Issued from MissQueue

To improve the efficiency of data refill and facilitate immediate DCache write after receiving refill data, the method of sending refill requests to MainPipe in advance is adopted. This completes the reading of metadata and selection of the replacement way. After receiving the hint signal returned by L2, the MissEntry corresponding to the request initiates a refill request to MainPipe. At this time, this refill request does not carry the specific data to be written back. While MainPipe performs metadata reading and replacement way selection, it continues to wait for the arrival of refill data. After receiving Grant/GrantData, the refill data block is directly passed to MainPipe's stage 2 through forwarding, matching with the refill request issued in advance to complete the write-back operation. After the write-back operation is completed, it receives the release signal returned by MainPipe, releases the corresponding MissEntry, and completes the current request.

Overall Block Diagram

The overall architecture of MissQueue is shown in 此图.

MissQueue Flowchart

Interface Timing

Request Interface Timing Example

此图 shows the interface timing after a load miss request enters MissQueue. After the request arrives, a MissEntry is allocated. In the next cycle, an Acquire request is sent to L2, waiting for the hint and data response. In the cycle after receiving the l2_hint signal, a refill request is initiated to MainPipe; after receiving the first beat of the Grant data, a mem_finish response is returned to L2. After receiving the last beat of the Grant data, in the next cycle, the refill data is forwarded to MainPipe's stage 2 via refill_info to complete the data write.

MissQueue Timing

MissEntry Module

Feature 1: Miss Entry Allocation, Merging, Rejection

  • Empty entry allocation: If a new miss request does not meet the merge or reject conditions, a new Miss Entry is allocated for the request.
  • Request merge conditions: When the block address of an allocated Miss Entry (request A) is the same as that of a new miss request B, request B can be merged under the following two conditions:
    • The Acquire request to L2 has not yet handshaked, and A is a load request, and B is a load or store request. That is, B can be merged before A successfully initiates a read request to L2, and they send Acquire together;
    • The Acquire to L2 has already been sent out, but Grant/GrantData has not yet been received, and A is a load or store request, and B is a load request. That is, new incoming load requests can be merged before refill, while store requests can only be merged before the acquire handshake.
  • Request reject conditions: In the following cases, the new miss request needs to be rejected. This request will be reissued after a certain period of time:
    • The block address of the new miss request is the same as that of a request in a certain Miss Entry, but it does not meet the request merge conditions;
    • The Miss Queue is full.

Feature 2: MissEntry State Design:

Miss Entry controls the execution of operations and their order through a series of state registers. s_* registers indicate whether the scheduled request has been sent. w_* registers indicate whether the acknowledgment to wait for has been returned. These registers are set to true.B in the initial state. When allocating a Miss Entry for a request, the corresponding s_* and w_* registers will be set to false.B. This indicates that the request has not yet been sent out and the response to wait for has not handshaked. 此表 and 此图 show the description of the meaning of each register and their execution order:

MissEntry State List
State Description
s_acquire Send AcquireBlock / AcquirePerm request to L2
w_grantfirst Wait to receive the first beat of GrantData, asserted high indicates received
w_grantlast Wait to receive the last beat of GrantData, asserted high indicates received
s_grantack Return acknowledgment to L2 after receiving data from L2, GrantAck can be returned when the first beat of Grant is received
s_mainpipe_req Send refill request to Main Pipe, refill data into DCache
w_mainpipe_resp Indicates that the atomic request has been sent to Main Pipe for refill into DCache, and the acknowledgment from Main Pipe has been received
w_l2hint Indicates that the current miss request has received the l2_hint signal, can be woken up, and can initiate a refill request to MainPipe
w_refill_resp Indicates that the refill request for non-atomic operations is completed, and the MissEntry can be released

MissEntry Flowchart

Feature 3: MissEntry Alias Handling

L1 DCache supports working with L2 to handle cache alias issues. When MissEntry sends an Acquire request to L2, it carries the alias bits of the request address (vaddr[13:12]) for L2 to save and judge whether there are alias issues needing processing. The specific processing flow for alias issues is detailed in the ProbeQueue section.