TXREQ

Function Description

The TXREQ module receives requests sent to the REQ channel from both the MainPipe and MSHR modules. It arbitrates between the two and buffers them using a queue, finally sending them out onto the CHI's TXREQ bus channel. Requests from the MainPipe output are unconditionally accepted, while requests from the MSHR may be blocked. Therefore, the TXREQ module needs to apply backpressure to the MSHR and flow control to the MainPipe input to ensure that requests on the MainPipe can enter TXREQ without being blocked.

Function Description

Feature 1: Flow control for MainPipe input

To ensure that requests on MainPipe can enter TXREQ non-blockingly at s3/s4/s5, when inflight = (number of requests on MainPipe at s1/s2/s3/s4/s5 that potentially need to enter TXREQ) + (number of valid items in the queue) ≥ (total number of items in the queue, size=16), the TXREQ module needs to apply backpressure to the MainPipe input at the s0 stage. (Since only MSHR sends requests downstream to TXREQ, and MSHR tasks enter the pipeline from s0, backpressure only needs to be applied to MSHR requests at s0). As the timing for s1 is tight, for MainPipe requests at s1 that might use TXREQ: it is initially assumed that all s1 requests will use TXREQ, and if s2 finds that it is not used, the inflight count is decremented by 1.

Let's denote the blocking condition as noSpace.

Feature 2: MSHR backpressure logic

MainPipe has higher arbitration priority than MSHR. Therefore, when a request from the MainPipe output is valid, backpressure needs to be applied to MainPipe (Translator's note: This seems contradictory to the first point in Feature 2 and the description in Feature 1 about MainPipe having higher priority and unconditionally accepted; likely means MSHR is stalled if MainPipe has a request ready).
When noSpace is true, backpressure needs to be applied to MainPipe (Translator's note: Again, this seems like a potential conflict or refers to stalling MSHR instead of MainPipe) for the following reasons: In the cycle an MSHR request is issued, MainPipe might not have a request competing with MSHR. However, MainPipe might have requests still in the s1/s2 stages. The MSHR request might preempt a free queue item that originally belonged to MainPipe, leading to an insufficient number of queue items when requests from MainPipe reach the s3/s4/s5 stages. Thus, MainPipe requests also need to be blocked in this situation (Translator's note: The logic here seems to describe stalling MSHR when noSpace is true, potentially due to future MainPipe needs, rather than stalling MainPipe itself. The original text says "阻塞住 MainPipe 的请求" - block MainPipe's requests, which is confusing given the overall description. Based on the flow control description in Feature 1, it's more likely MSHR is stalled to reserve space for MainPipe. Will translate literally but add a note about the potential ambiguity).

Overall Block Diagram