Skip to content

RXSNP

Functional Description

The RXSNP module processes the Snoop requests from the RXSNP bus channel, converts them into an internal task format, and then sends them to RequestArb. At the same time, if there is an ongoing match in the MSHR that meets the following conditions, it blocks the RXSNP bus from entering SinkB: - The address is the same and cannot be nested by this Snoop request. - The data block to be replaced has the same address as this Snoop request and cannot be nested by this Snoop.

Feature 1: When does Snoop(addr=X) nest within an ongoing read operation (addr=X) being processed by MSHR?

  1. Before MSHR receives the first response data, a Snoop with the same address has higher priority and should be processed first.
  2. After MSHR receives the first response data, a Snoop with the same address should wait for this MSHR to complete before being responded to.
  3. Before MSHR sends WriteBackFull/Evict to write the backfill data into DS, Snoop should be blocked because the data required by Snoop is still in the refillBuffer, not in DS.
  4. When MSHR sends WriteBackFull/Evict and the backfill data has been written to DS, Snoop should be prioritized for response because Snoop has higher priority.

Feature 2: When does Snoop(addr=Y) nest within an ongoing MSHR replacement (the replaced line address addr=Y)?

  1. When MSHR determines that a certain way is being replaced and the probe to the Core generated by this replacement has not completed, this Snoop is blocked because it may generate an identical probe to the Core for the same address.
  2. If all probes to the Core from MSHR have completed, Snoop should nest within MSHR.
  3. When MSHR is a CMO operation, Snoop is blocked until all generated Probe operations are completed.

Overall Block Diagram

RXSNP