MMIO Bridge MMIOBridge
The MMIOBridge is independent of the 4 Slices in CoupledL2. It receives MMIO and Uncache requests from the IFU / LSU and interacts with the downstream NoC / LLC via the CHI bus to complete peripheral read/write operations. By default, the MMIOBridge includes 8 MMIOBridgeEntries. Each MMIOBridgeEntry is an independent state machine used to process one MMIO or Uncache request.
State Machine
The state machine items are mainly divided into two categories:
- Schedule state items
- Wait state items
Schedule state items are also called active action state items. They are mainly used to track the situation where the MMIOBridgeEntry actively sends tasks and requests to the upstream TileLink bus and downstream CHI bus. Their value is low-active, indicating an incomplete state, meaning the task has not successfully left the MMIOBridgeEntry and been issued. The reasons could be an unfulfilled blocking condition (necessary prerequisite action not completed) or channel blocking. A high value indicates that the corresponding task has been successfully issued or does not need to be issued.
Wait state items are also called passive action state items. They are mainly used to track the replies the MMIOBridgeEntry expects to receive from the downstream CHI channel and upstream TileLink channel. Their value is low-active, indicating an incomplete state, meaning the corresponding reply has not yet returned to the current entry. A high value indicates that the corresponding reply has been received or does not need to be received.
State registers include:
| Name | Description |
|---|---|
s_txreq |
Send ReadNoSnp / WriteNoSnpPtl requests to the downstream TXREQ channel |
s_ncbwrdata |
(If it is a write operation) Send NCBWrData packet to the downstream TXDAT. Sending NCBWrData is premised on w_dbidresp being high. |
s_resp |
CHI read/write transaction is complete, return AccessAckData / AccessAck response to the upstream TileLink D channel |
w_comp |
(If it is a write operation) Wait for Comp / CompDBIDResp response from the downstream RXRSP channel |
w_dbidresp |
(If it is a write operation) Wait for CompDBIDResp / DBIDResp / DBIDRespOrd response from the downstream RXRSP channel |
w_compdata |
(If it is a read operation) Wait for CompData from the downstream RXDAT channel |
w_pcrdgrant |
Protocol-level retransmission occurred for a read/write request, need to wait for PCrdGrant from downstream |
w_readreceipt |
(If it is a read request and Order is not None) Wait for ReadReceipt from the downstream RXRSP channel |
Ordering
The default Order for CHI requests initiated by MMIOBridge is RequestOrder or EndpointOrder. When the core initiates a TileLink read/write request, it carries information in the A channel's custom field about whether the PMA attribute of the address is Memory:
- If the PMA attribute of the address is Memory, but the PBMT attribute is IO or NC, the Order of the initiated CHI transaction is RequestOrder.
- If the PMA attribute of the address is Memory, but the PBMT attribute is IO or NC, the Order of the initiated CHI transaction is EndpointOrder.
Whether it is RequestOrder or EndpointOrder, the initiated ReadNoSnp requires the downstream to return ReadReceipt for ordering read operations. Therefore, MMIOBridge monitors whether each entry is waiting for ReadReceipt (i.e., whether w_readreceipt is low). If an entry is waiting for ReadReceipt, no entry can send a new ReadNoSnp downstream.
Memory Attributes
The CHI bus protocol defines memory attributes across the following 4 dimensions:
- Allocate
- Cacheable
- Device
- EWA (Early Write Acknowledgment)
For requests initiated by MMIOBridge, Allocate and Cacheable are always 0. Device depends on the PMA attribute; if the PMA attribute is Memory, Device is 0, otherwise Device is 1. EWA can be understood as whether the address can be Buffered; if the PMA attribute of the address is Memory, or if the PMA attribute is not Memory but the PBMT attribute is NC, the address is considered bufferable, and EWA is set to 1, otherwise EWA is set to 0.
P-Credit Arbitration
MMIOBridge supports protocol-level retransmission on the CHI bus. According to the CHI bus protocol, a transaction can only initiate a protocol-level retransmission after receiving RetryAck and PCrdGrant. The RetryAck's TxnID matches the TxnID of the request on the TXREQ channel, thus RetryAck can be uniquely matched to an entry in the MMIOBridge via the TxnID. However, PCrdGrant only needs the SrcID and PCrdType fields to match the RetryAck, and cannot be directly matched to an entry in MMIOBridge via TxnID.
Based on the above CHI protocol regulations, when CoupledL2 receives a PCrdGrant, it cannot directly determine whether this P-Credit should be arbitrated to MMIOBridge or the 4 Slices based on the PCrdGrant's fields, let alone how to map the P-Credit to a specific MMIOBridgeEntry or MSHR entry. Therefore, the P-Credit arbitration logic is located at the top level of CoupledL2. When a PCrdGrant is received, CoupledL2 temporarily stores it in a register bank at the top level (mainly recording critical fields such as SrcID and PCrdType). MSHR / MIOBridgeEntry entries that have received RetryAck will match their RetryAck's SrcID and PCrdType with the PCrdGrant register bank. If a match is found, that entry in the register bank will be released. If no match is found, it will continue to wait for a downstream PCrdGrant until a match is successful.