MSHR

Whether each task is assigned an MSHR is determined by the memory access pipeline (MainPipe) based on factors such as whether it hits, whether it needs to Probe L1, the complexity of the processing flow, etc. See Request Arbiter and Memory Access Pipeline for details.

Life Cycle

Each MSHR entry has its own life cycle. An MSHR entry is allocated by the MainPipe and its life cycle ends after it completes all tasks and clears all state machine state items. Each MSHR entry may remain valid for a relatively long time while waiting for bus transactions, but it must complete its life cycle within a finite time, otherwise it indicates livelock or deadlock.

MSHR ID

Each MSHR entry has its own ID value, which is hardcoded, and the ID values are different for each MSHR.

For CHI requests initiated by an MSHR, the low bits of the TxnID value are bound to the MSHR ID.

Allocation

When the MainPipe requests to allocate an MSHR entry, the MSHRSelector inside the MSHRCtl module selects an unallocated MSHR. When allocating each MSHR, the MainPipe needs to provide the following information:

The hit status and consistency state of the cache line
The initial state of the MSHR state machine
Necessary original information of the request (from TileLink request or CHI request)
The nesting situation of the request and the ongoing writeback (L2 downward TileLink Release or CHI Copy-Back Write)

This information will be registered within the allocated MSHR entry.

Release

When all state machine items within the MSHR are set to complete, it can be released in place immediately, ending the life cycle of that MSHR entry and preparing it to be selected and allocated by the MSHRSelector again. For details on MSHR state machine items, see State Machine.

State Machine

State machine items are mainly divided into two categories:

Schedule state items
Wait state items

Schedule state items, also known as active action state items, are mainly used to track the situation where the MSHR actively sends tasks and requests to the MainPipe, downstream CHI channel, and upstream TileLink channel. Their value is active low, indicating an incomplete state, meaning the task has not successfully left the MSHR and been issued. The reason may be that blocking conditions are not met (necessary preceding actions are not completed) or the channel is blocked; a high value indicates that the corresponding task has been successfully issued or does not need to be issued.

Wait state items, also known as passive action state items, are mainly used to track the expected responses from the downstream CHI channel, upstream TileLink channel, or CoupledL2 internal modules. Their value is active low, indicating an incomplete state, meaning the corresponding response has not yet returned to the MSHR entry; a high value indicates that the corresponding response has been received or does not need to be received.

State items are assigned when the MSHR is allocated by the MainPipe and are also changed by actions within the MSHR.

Upstream in this subsection typically refers to L1 cache, and downstream typically refers to NoC, LLC, etc.

Schedule state items are named with s_ as the prefix. Their overview is as follows:

Name	Description
`s_acquire`	First time needing to send a permission upgrade request or CMO request downstream, or needing to send a retried writeback or evict request downstream
`s_rprobe`	Due to replacement or writeback, needs to send a Probe request upstream
`s_pprobe`	Due to a downstream Snoop request, needs to send a Probe request upstream
`s_release`	Writeback or evict request needing to be sent downstream
`s_probeack`	Due to a downstream Snoop request, needs to send a Snoop response downstream
`s_refill`	Needs to send a Grant response upstream
`s_retry`	Due to no free way for replacement, the Grant response sent upstream needs to be retried
`s_cmoresp`	Needs to send a CBOAck response upstream
`s_cmometaw`	CMO-induced directory update request sent to MainPipe
`s_rcompack`	Due to sending a read request downstream, needs to send the corresponding CompAck response
`s_wcompack`	Due to sending a write request downstream, needs to send the corresponding CompAck response
`s_cbwrdata`	Due to sending a write request downstream, needs to send the corresponding CopyBackWrData to write back data
`s_reissue`	Due to receiving RetryAck from downstream and the MSHR having obtained P-Credit, needs to re-send the request downstream
`s_dct`	Due to a downstream Forwarding Snoop request, needs to send CompData in the form of DCT to provide data to other RNs

Wait state items are named with w_ as the prefix. Their overview is as follows:

Name	Description
`w_rprobeackfirst`	Due to replacement or writeback, a Probe request was sent upstream, needs to wait to receive the first Probe response from upstream
`w_rprobeacklast`	Due to replacement or writeback, a Probe request was sent upstream, needs to wait to receive the last Probe response from upstream (same action as `w_rprobeackfirst` for single responses)
`w_pprobeackfirst`	Due to a downstream Snoop request, a Probe request was sent upstream, needs to wait to receive the first Probe response from upstream
`w_pprobeacklast`	Due to a downstream Snoop request, a Probe request was sent upstream, needs to wait to receive the last Probe response from upstream (same action as `w_pprobeackfirst` for single responses)
`w_grantfirst`	Due to sending a permission upgrade request or CMO request downstream, needs to wait for the first Comp, CompData, or DataSepResp response from downstream
`w_grantlast`	Due to sending a permission upgrade request or CMO request downstream, needs to wait for the last CompData or DataSepResp response from downstream (same action as `w_grantfirst` when receiving a Comp response)
`w_grant`	Due to sending a permission upgrade request or CMO request downstream, needs to wait for a Comp, CompData, or RespSepData response from downstream and obtain necessary DBID and SrcID information in CompData and RespSepData responses
`w_releaseack`	Due to a writeback request or evict request sent downstream, needs to wait for a Comp or CompDBIDResp response from downstream
`w_replResp`	Due to replacement, needs to wait for the replacement selection result from the Directory

Task Distribution

When a Schedule state item is incomplete, the MSHR will attempt to send the corresponding task to the relevant module or channel. Each MSHR entry can be directly distributed to the following modules/channels after arbitration by MSHRCtl:

MainPipe
Upstream TileLink B channel
Downstream TXREQ channel
Downstream TXRSP channel

Distribution of tasks to the TXDAT channel must go through the MainPipe. See Request Arbiter and Memory Access Pipeline for details.

Tasks sent to the MainPipe will also undergo arbitration by the RequestArb in the same cycle. See Request Arbiter and Memory Access Pipeline for details.

The task distribution directions corresponding to each Schedule state item are shown in the table below:

Name	Target Module/Channel
`s_acquire`	Downstream TXREQ channel
`s_rprobe`	Upstream TileLink B channel
`s_pprobe`	Upstream TileLink B channel
`s_release`	MainPipe
`s_probeack`	MainPipe
`s_refill`	MainPipe
`s_retry`	-
`s_cmoresp`	MainPipe
`s_cmometaw`	MainPipe
`s_rcompack`	Downstream TXRSP channel
`s_wcompack`	Downstream TXRSP channel
`s_cbwrdata`	MainPipe
`s_reissue`	-
`s_dct`	MainPipe

MainPipe

Each MSHR will send several different types of tasks to the MainPipe based on the state of its state machine items.

Writeback Request Task (`mp_release`)

The writeback request task (mp_release) is triggered by the state machine item s_release. The function of this task is for the MainPipe to send the required cache line writeback request or evict request through the TXREQ channel. When the state of the state machine item s_release is incomplete and the current state of the MSHR meets certain conditions, the MSHR will attempt to send a writeback request task to the MainPipe.

When s_release is set to incomplete, for the writeback request task to be sent to the MainPipe, the MSHR state needs to satisfy the following conditions in various cases:

From a replacement task
- Replacement way selection has been completed
- All responses to the upstream Probe have been received
- All data from downstream has been received for the replacement read request
From a CMO request
- All responses to the upstream Probe have been received

The writeback request task will require the MainPipe to send requests to the TXREQ channel:

Task Source	Upstream A Channel Request Type	Has Dirty Data	Downstream TXREQ Request Type
Replacement task	Acquire*	Yes	WriteBackFull
		No	WriteEvictOrEvict
CMO request	CBOClean	-	WriteCleanFull
	CBOFlush	Yes	WriteBackFull
		No	Evict
	CBOInval	-	Evict

The writeback request task will conditionally require the MainPipe to write the associated data held by the MSHR into DataStorage:

Task Source	Upstream A Channel Request Type	Has Dirty Data	Data Source	Write to DataStorage
Replacement task	Acquire*	-	RefillBuffer	Yes
CMO request	CBO*	From upstream Probe response	ReleaseBuffer	Yes
		Other	-	No

Furthermore, for CMO requests, the writeback request task requires the MainPipe to update the cache line state in the Directory and clear the cache line's Dirty flag:

Task Source	Upstream A Channel Request Type	Initial State	State to Write
CMO request	CBOClean	TRUNK	TIP
		TIP	TIP
		BRANCH	BRANCH
		INVALID	INVALID
	CBOFlush	-	INVALID
	CBOInval	-	INVALID

Downstream Snoop Response Task (`mp_probeack`)

The downstream Snoop response task (mp_probeack) is triggered by the state machine item s_probeack. The function of this task is for the MainPipe to send a Snoop response downstream through the TXRSP or TXDAT channel. When the state of the state machine item s_probeack is incomplete and the current state of the MSHR meets certain conditions, the MSHR will attempt to send a downstream Snoop response task to the MainPipe.

When s_probeack is set to incomplete, for the downstream Snoop response task to be sent to the MainPipe, the MSHR state needs to satisfy the following conditions:

All responses to the upstream Probe have been received

The downstream Snoop response task will require the MainPipe to send messages through the TXRSP or TXDAT channel and specify the type of Snoop Response within the MSHR. See Snoop Processing for details.

The downstream Snoop response task will require the MainPipe to write the associated data held by the MSHR into DataStorage under the following circumstances:

The target state of the downstream Snoop request is not I
The upstream L1 returned dirty data during the Probe process (ProbeAckData)
The upstream L1 did not nestedly initiate a writeback of dirty data before the Probe ended (ReleaseData)

The downstream Snoop response task will require the MainPipe to update the cache line state. See Snoop Processing for details.

Replacement Way Query and Upstream Grant/CBOAck Response Task (`mp_grant`)

The replacement way query and upstream Grant/CBOAck response task (mp_grant) is triggered by the state machine item s_refill or s_cmoresp, and s_refill and s_cmoresp will not be set to incomplete simultaneously. The function of this task is one of the following:

The MainPipe initiates a replacement way query request to the Directory
The MainPipe sends Grant/GrantData responses upstream through the TileLink D channel
The MainPipe sends CBOAck responses upstream through the TileLink D channel

When the state of the state machine item s_release is incomplete and the current state of the MSHR meets certain conditions, the MSHR will attempt to send a replacement way query or upstream Grant response task to the MainPipe; when the state of the state machine item s_cmoresp is incomplete and the current state of the MSHR meets certain conditions, the MSHR will attempt to send a CBOAck response task to the MainPipe.

When s_refill is set to incomplete, for the replacement way query and upstream Grant response task to be sent to the MainPipe, the MSHR state needs to satisfy the following conditions:

All responses to the upstream Probe have been received
The first Comp, CompData, or RespSepData response from downstream has been received
If needed, all Comp, CompData, or DataSepResp responses from downstream have been received
Replacement way query retries have not exceeded the retry suppression threshold

After sending multiple replacement way retry requests consecutively, the MSHR will suppress them for a period of time to prevent excessively dense, consecutive retries from causing livelock.

When s_cmoresp is set to incomplete, for the replacement way query and upstream CBOAck response task to be sent to the MainPipe, the MSHR state needs to satisfy the following conditions:

All responses to the upstream Probe have been received
The Comp response from downstream belonging to w_releaseack has been received
The Comp response from downstream belonging to w_grant has been received (w_grant can only receive the downstream Comp response after w_releaseack is completed)
If needed, all CopyBackWrData have been sent

And these conditions imply a characteristic: s_cmoresp can only initiate the task after all CMO sub-actions other than the CBOAck response process are completed.

When the MSHR needs to wait for the replacement way result and the Directory provides a retry response, the MSHR will send a replacement way retry task from mp_grant.

The replacement way query and upstream Grant task will require the MainPipe to update the cache line state in the Directory. If it is an upstream CBOAck task, it will not require this. The update rules are as follows:

Task Source	Request Type	Initial State	Update State
`s_refill`	Get	TIP	TIP
		TRUNK	TIP
		BRANCH	BRANCH
		INVALID	TIP`*`
			BRANCH
	Acquire* toT	-	TRUNK
	Acqurie* toB	-	TRUNK`*`
		-	BRANCH
	Hint PrefetchWrite	-	TIP
	Hint PrefetchRead	-	TIP`*`
		-	BRANCH
`s_cmoresp`	-	-	-

Where updating Get to TIP, Acquire* toB to TRUNK, and Hint PrefetchRead to TIP will occur in the following situations:

The cache line does not exist in the upstream L1 and has TIP permission locally in L2
The operation being performed on the cache line is not Alias replacement, and it has TIP or TRUNK permission locally in L2
The cache line does not exist in L2, and the read request sent downstream returned write permission

The replacement way query and upstream Grant task will require the MainPipe to update the corresponding Tag value of the selected replacement cache line in the Directory if a Directory miss occurs. If it is an upstream CBOAck task, this is not required.

The replacement way query and upstream Grant/CBOAck task will require the MainPipe to write the associated data held by the MSHR into DataStorage if one of the following conditions is met:

Received CompData or DataSepResp data response from downstream
Received dirty data in the upstream Probe response when completing a Get or Alias replacement flow

Downstream CopyBackWrData Task (`mp_cbwrdata`)

The writeback request task (mp_cbwrdata) is triggered by the state machine item s_cbwrdata. The function of this task is for the MainPipe to complete the CopyBackWrData that needs to be sent downstream through the TXDAT channel. When the state of the state machine item s_cbwrdata is incomplete and the current state of the MSHR meets certain conditions, the MSHR will attempt to send a writeback request task to the MainPipe.

s_cbwrdata is usually set to incomplete by the following actions of s_release and w_releaseack:

The writeback request task is leaving the MSHR, i.e., the s_release state item is being set to complete

It should be noted that when receiving a Comp response after sending WriteEvictOrEvict, s_cbwrdata will be set to complete without the MSHR sending any downstream CopyBackWrData tasks to the MainPipe.

For the writeback request task to be sent to the MainPipe, the MSHR state needs to satisfy the following conditions:

The writeback request task has left the MSHR, i.e., the s_release state item is complete

Downstream DCT CompData Task (`mp_dct`)

The downstream DCT CompData task (mp_dct) is triggered by the state machine item s_dct. The function of this task is for the MainPipe to complete the DCT part of the Forwarding Snoop through the TXDAT channel. When the state of the state machine item s_dct is incomplete and the current state of the MSHR meets certain conditions, the MSHR will attempt to send a downstream DCT CompData task to the MainPipe.

When s_dct is set to incomplete, for the downstream DCT CompData task to be sent to the MainPipe, the MSHR state needs to satisfy the following conditions:

The Snoop response task targeting the HN in the Forwarding Snoop flow has left the MSHR, i.e., the s_probeack state item is complete

The downstream DCT CompData task will require the MainPipe to send a CompData response through the TXDAT channel. And according to the definition of DCT, the target of this CompData response is another processor core (i.e., RN).

CMO Cache State Update Task (`mp_cmometaw`)

The CMO cache state update task (mp_cmometaw) is triggered by the state machine item s_cmometaw. The function of this task is for the MainPipe to update the cache line state when a CBOClean operation does not require a WriteCleanFull writeback.

When s_cmometaw is set to incomplete, the MSHR can send a CMO cache state update task to the MainPipe and perform the following updates:

Update the record to indicate that the cache line does not exist in the upstream L1 when receiving ProbeAck toN
Clear the state to Clean
Update the permission to TIP

Upstream TileLink B Channel

Requests sent to the upstream TileLink B channel are triggered by the state machine item s_pprobe or s_rprobe. And s_pprobe and s_rprobe will not be set to incomplete simultaneously.

When either of the state machine items s_pprobe or s_rprobe is set to incomplete, the MSHR can send a request to the upstream TileLink B channel. The request types in various cases are shown in the table below:

Task Source	Upstream Request Type	Downstream Request Type	Cache Line State	Sent Request Type
`s_pprobe`	-	SnpOnce	-	Probe toT
	-	SnpClean	-	Probe toB
	-	SnpShared	-	Probe toB
	-	SnpNotSharedDirty	-	Probe toB
	-	SnpUnique	-	Probe toN
	-	SnpCleanShared	-	Probe toT
	-	SnpCleanInvalid	-	Probe toN
	-	SnpMakeInvalid	-	Probe toN
	-	SnpMakeInvalidStash	-	Probe toN
	-	SnpUniqueStash	-	Probe toN
	-	SnpStashUnique	-	Probe toT
	-	SnpStashShared	-	Probe toT
	-	SnpOnceFwd	-	Probe toT
	-	SnpCleanFwd	-	Probe toB
	-	SnpNotSharedDirtyFwd	-	Probe toB
	-	SnpSharedFwd	-	Probe toB
	-	SnpUniqueFwd	-	Probe toN
	-	SnpQuery	-	Probe toT
`s_rprobe`	Get	-	TRUNK	Probe toB
	Acquire*	-	-	Probe toN
	CBOClean	-	TRUNK	Probe toB

Downstream TXREQ Channel

Requests sent to the downstream TXREQ channel are triggered by the state machine item s_acquire or s_reissue. And s_acquire and s_reissue will not be set to incomplete simultaneously.

When s_acquire is set to incomplete, for replacement tasks, a permission upgrade request can be sent downstream immediately. However, for CMO tasks, the following conditions must be met before a CMO request can be sent downstream:

All responses to the upstream Probe have been received
A Comp or CompDBIDResp has been received for the downstream writeback request
The downstream CopyBackWrData task has left the MSHR or this task is not needed

When s_reissue is set to incomplete, the following conditions must be met before a retried request can be re-sent downstream:

RetryAck from downstream has been received
PCrdGrant from downstream has been received and allocated to the corresponding MSHR transaction
In a state where an mp_release or downstream TXREQ channel task has left the MSHR but no response has been received, i.e., the s_release state item is complete but the w_releaseack state item is incomplete, or the s_acquire state item is complete but the w_grant state item is incomplete

The types of requests sent to the downstream TXREQ channel in various cases are shown in the table below:

Task Source	Incomplete State	Upstream Request Type	Incomplete Request Type	Sent Request Type
`s_acquire`	-	Get	-	ReadNotSharedDirty
		AcquirePerm toT	-	MakeUnique
		AcquireBlock toT	-	ReadUnique
		AcquireBlock toB	-	ReadNotSharedDirty
		Hint PrefetchWrite	-	ReadUnique
		Hint PrefetchRead	-	ReadNotSharedDirty
		CBOClean	-	CleanShared
		CBOFlush	-	CleanInvalid
		CBOInval	-	MakeInvalid
`s_reissue`	`w_grant`	Get	ReadNotSharedDirty	ReadNotSharedDirty
		AcquirePerm toT	MakeUnique	MakeUnique
		AcquireBlock toT	ReadUnique	ReadUnique
		AcquireBlock toB	ReadNotSharedDirty	ReadNotSharedDirty
		Hint PrefetchWrite	ReadUnique	ReadUnique
		Hint PrefetchRead	ReadNotSharedDirty	ReadNotSharedDirty
		CBOClean	CleanShared	CleanShared
		CBOFlush	CleanInvalid	CleanInvalid
		CBOInval	MakeInvalid	MakeInvalid
`s_reissue`	`w_releaseack`	Acquire*	WriteBackFull	WriteBackFull
			WriteEvictOrEvict	WriteEvictOrEvict
		CBOClean	WriteCleanFull	WriteCleanFull
		CBOFlush	WriteBackFull	WriteBackFull
			Evict	Evict
		CBOInval	Evict	Evict

Downstream TXRSP Channel

Messages sent to the downstream TXRSP channel are triggered by the state machine item s_rcompack or s_wcompack. This channel is mainly used to send CompAck messages downstream. s_rcompack and s_wcompack may be set to incomplete simultaneously, and s_rcompack has higher priority.

When s_rcompack is set to incomplete, the following conditions must be met before a CompAck message can be sent downstream:

When configured as Issue B
- Received Comp or all CompData from downstream
When configured as Issue C and newer versions
- Received Comp or the first CompData or RespSepData and the first DataSepResp from downstream

When s_wcompack is set to incomplete, the following conditions must be met before a CompAck message can be sent downstream:

s_rcompack is complete or not set to incomplete

Snoop Processing

Non-Nested Snoop

When there is no incomplete writeback request for the same address, a received Snoop is a non-nested, ordinary Snoop, which is the most basic processing case for Snoops. The processing method for non-nested Snoops in the MSHR is as follows:

Snoop Request Type	Initial State	Final State	RetToSrc	Snoop Response
SnpOnce	I	-	-	-
	UC	UC	X	SnpRespData_UC
	UD	UD	X	SnpRespData_UD_PD
	SC	-	-	-
SnpClean,	I	-	-	-
SnpShared,	UC	SC	X	SnpResp_SC
SnpNotSharedDirty	UD	SC	X	SnpRespData_SC_PD
	SC	-	-	-
SnpUnique	I	-	-	-
	UC	I	X	SnpResp_I
	UD	I	X	SnpRespData_I_PD
	SC	I	0	SnpResp_I
			1	SnpRespData_I
SnpCleanShared	I	-	-	-
	UC	UC	0	SnpResp_UC
	UD	UC	0	SnpRespData_UC_PD
	SC	-	-	-
SnpCleanInvalid	I	-	-	-
	UC	I	0	SnpResp_I
	UD	I	0	SnpRespData_I_PD
	SC	I	0	SnpResp_I
SnpMakeInvalid	-	I	0	SnpResp_I
SnpMakeInvalidStash	-	I	0	SnpResp_I
SnpUniqueStash	I	-	-	-
	UC	I	0	SnpResp_I
	UD	I	0	SnpRespData_I_PD
	SC	I	0	SnpResp_I
SnpStashUnique,	I	-	-	-
SnpStashShared	UC	UC	0	SnpResp_UC
	UD	UD	0	SnpResp_UD
	SC	-	-	-
SnpOnceFwd	I	I	0	SnpResp_I
	UC	UC	0	SnpResp_UC_Fwded_I
	UD	UD	0	SnpResp_UD_Fwded_I
	SC	SC	0	SnpResp_SC_Fwded_I
SnpCleanFwd,	I	I	X	SnpResp_I
SnpNotSharedDirtyFwd,	UC	SC	0	SnpResp_SC_Fwded_SC
SnpSharedFwd			1	SnpRespData_SC_Fwded_SC
	UD	SC	X	SnpRespData_SC_PD_Fwded_SC
	SC	SC	0	SnpResp_SC_Fwded_SC
			1	SnpRespData_SC_Fwded_SC
SnpUniqueFwd	I	I	0	SnpResp_I
	UC	I	0	SnpResp_I_Fwded_UC
	UD	I	0	SnpResp_I_Fwded_UD_PD
	SC	I	0	SnpResp_I_Fwded_UC
SnpQuery	I	-	-	-
	UC	UC	0	SnpResp_UC
	UD	UD	0	SnpResp_UD
	SC	-	-	-

"-" and unlisted cache states indicate that this type of request in the corresponding situation will not enter the MSHR.

For details on when specific Snoop requests will allocate an MSHR, see Request Arbiter and Memory Access Pipeline.

Nested Snoop

When the MSHR is processing a writeback request downstream, it still needs to ensure that CoupledL2 can respond to downstream Snoop requests and upstream Release requests. In this case, the incomplete writeback request is considered to be nested by a Snoop request, or nested by an upstream Release request. It should be noted that due to the presence of Silent Eviction in the CHI protocol, and the initial state of an Evict request is I, an evict request (Evict) that does not involve data writeback will not be considered nested.

"-" and unlisted cache states indicate that this type of request in the corresponding situation will not enter the MSHR, or is not within the scope of nesting.

For details on when specific Snoop requests will allocate an MSHR, see Request Arbiter and Memory Access Pipeline.

The downstream Snoop request nesting that may occur and be processed within the MSHR is as follows.

Characteristic 1: Nesting of Snoop and WriteBackFull

Snoop Request Type	Initial State	State Before Nesting	State After Nesting	RetToSrc	Snoop Response
SnpOnce	-	-	-	-	-
SnpClean	-	-	-	-	-
SnpShared	-	-	-	-	-
SnpNotSharedDirty	-	-	-	-	-
SnpCleanShared	-	-	-	-	-
SnpCleanInvalid	-	-	-	-	-
SnpMakeInvalid	-	-	-	-	-
SnpUnique	-	-	-	-	-
SnpUniqueStash	-	-	-	-	-
SnpMakeInvalidStash	-	-	-	-	-
SnpStashUnique	-	-	-	-	-
SnpStashShared	-	-	-	-	-
SnpOnceFwd	UD	UD	I	X	SnpRespData_I_PD_Fwded_I
SnpCleanFwd	UD	UD	I	X	SnpRespData_I_PD_Fwded_SC
SnpSharedFwd	UD	UD	I	X	SnpRespData_I_PD_Fwded_SC
SnpNotSharedDirtyFwd	UD	UD	I	X	SnpRespData_I_PD_Fwded_SC
SnpUniqueFwd	UD	UD	I	X	SnpResp_I_Fwded_UD_PD
SnpQuery	-	-	-	-	-

Characteristic 2: Nesting of Snoop and WriteEvictOrEvict

Snoop Request Type	Initial State	State Before Nesting	State After Nesting	RetToSrc	Snoop Response
SnpOnce	-	-	-	-	-
SnpClean	-	-	-	-	-
SnpShared	-	-	-	-	-
SnpNotSharedDirty	-	-	-	-	-
SnpCleanShared	-	-	-	-	-
SnpCleanInvalid	-	-	-	-	-
SnpMakeInvalid	-	-	-	-	-
SnpUnique	-	-	-	-	-
SnpUniqueStash	-	-	-	-	-
SnpMakeInvalidStash	-	-	-	-	-
SnpStashUnique	-	-	-	-	-
SnpStashShared	-	-	-	-	-
SnpOnceFwd	UC	UC	I	X	SnpRespData_I_Fwded_I
SnpCleanFwd	UC	UC	I	0	SnpResp_I_Fwded_SC
				1	SnpRespData_I_Fwded_SC
SnpSharedFwd	UC	UC	I	0	SnpResp_I_Fwded_SC
				1	SnpRespData_I_Fwded_SC
SnpNotSharedDirtyFwd	UC	UC	I	0	SnpResp_I_Fwded_SC
				1	SnpRespData_I_Fwded_SC
SnpUniqueFwd	UC	UC	I	0	SnpResp_I_Fwded_UC
SnpQuery	-	-	-	-	-

Characteristic 3: Nesting of Snoop and WriteCleanFull

Snoop Request Type	Initial State	State Before Nesting	State After Nesting	RetToSrc	Snoop Response
SnpOnce	-	-	-	-	-
SnpClean	-	-	-	-	-
SnpShared	-	-	-	-	-
SnpNotSharedDirty	-	-	-	-	-
SnpCleanShared	-	-	-	-	-
SnpCleanInvalid	UD	UD	I	0	SnpRespData_I_PD
		UC	I	0	SnpResp_I
		SC	I	0	SnpResp_I
SnpMakeInvalid	UD	UD	I	0	SnpResp_I
		UC	I	0	SnpResp_I
		SC	I	0	SnpResp_I
SnpUnique	UD	UD	I	X	SnpRespData_I_PD
		UC	I	X	SnpResp_I
		SC	I	0	SnpResp_I
				1	SnpRespData_I
SnpUniqueStash	UD	UD	I	0	SnpRespData_I_PD
		UC	I	0	SnpResp_I
		SC	I	0	SnpResp_I
SnpMakeInvalidStash	UD	UD	I	0	SnpResp_I
		UC	I	0	SnpResp_I
		SC	I	0	SnpResp_I
SnpStashUnique	-	-	-	-	-
SnpStashShared	-	-	-	-	-
SnpOnceFwd	UD	UD	SC	0	SnpRespData_SC_PD_Fwded_I
		UC	UC	0	SnpResp_UC_Fwded_I
		SC	SC	0	SnpResp_SC_Fwded_I
SnpCleanFwd	UD	UD	SC	X	SnpRespData_SC_PD_Fwded_SC
		UC	SC	0	SnpResp_SC_Fwded_SC
				1	SnpRespData_SC_Fwded_SC
		SC	SC	0	SnpResp_SC_Fwded_SC
				1	SnpRespData_SC_Fwded_SC
SnpSharedFwd	UD	UD	SC	X	SnpRespData_SC_PD_Fwded_SC
		UC	SC	0	SnpResp_SC_Fwded_SC
				1	SnpRespData_SC_Fwded_SC
		SC	SC	0	SnpResp_SC_Fwded_SC
				1	SnpRespData_SC_Fwded_SC
SnpNotSharedDirtyFwd	UD	UD	SC	X	SnpRespData_SC_PD_Fwded_SC
		UC	SC	0	SnpResp_SC_Fwded_SC
				1	SnpRespData_SC_Fwded_SC
		SC	SC	0	SnpResp_SC_Fwded_SC
				1	SnpRespData_SC_Fwded_SC
SnpUniqueFwd	UD	UD	I	0	SnpResp_I_Fwded_UD_PD
		UC	I	0	SnpResp_I_Fwded_UC
		SC	I	0	SnpResp_I_Fwded_UC
SnpQuery	-	-	-	-	-

Writeback Nesting Handling

When nesting might occur, each MSHR receives request nesting information broadcast by the MainPipe, which includes the Tag and Set address of the potentially nested cache line and the nesting behavior. The specific signals are the nestwb port within the MSHR and the NestedWriteback Bundle class.

Considering the upstream Release/ReleaseData requests and downstream Snoop requests that can cause nesting, the various nesting handling logic required within the MSHR is as follows.

Characteristic 1: Nesting of the Cache Line Being Replaced with Upstream ReleaseData TtoN

This type of nesting occurs when the Tag and Set address of the cache line being replaced in the MSHR are the same as the Tag and Set address of the ReleaseData TtoN broadcast by the MainPipe to each MSHR. The corresponding signal name is c_set_dirty.

This nesting typically occurs when CoupledL2 has already sent or is sending a Probe toN request caused by replacement to the upstream L1 cache, and before CoupledL2 has observed the response from the upstream L1 cache to this Probe toN, the upstream L1 cache actively initiates a ReleaseData TtoN to CoupledL2.