3. CCIX協議層（續）

3.3 一致性協議

3.3.1 緩存狀態

CCIX協議規定的緩存狀態如下：

I（Invalid）：緩存行無效，即緩存行不存在于緩存中。

UC（Unique Clean）：緩存行的狀態是唯一且“干凈”，即緩存行只存在當前緩存中，且緩存行沒有被修改過。擁有該緩存行的處理器可以在不通知其它緩存的情況下修改此緩存行。當前緩存接收到監聽消息時，如果DataRet（Data Return to Source）字段被置為1，可以（但不要求）返回該條緩存行數據；如果DataRet字段被置為0，不可以返回該條緩存行數據。

UCE（Unique Clean Empty）：緩存行只在當前緩存中存在，緩存行處于唯一狀態，但所有數據字節均無效。擁有該緩存行的處理器可以在不通知其它緩存的情況下修改緩存行。當前緩存接收到請求數據的監聽消息時，不可以返回該條緩存行（因為所有數據無效）。

UD（Unique Dirty）：緩存行的狀態是唯一但為“臟“，即緩存行只在當前緩存中存在，但是緩存行數據被修改過，且沒有更新到內存。當該緩存行被逐出（eviction）時，必須寫回下一級緩存或內存。擁有該緩存行的處理器以在不通知其它緩存的情況下修改緩存行數據。當前緩存接收到請求數據的監聽消息時，必須返回該緩存行數據。

UDP（Unique Dirty Partial）：緩存行的狀態是唯一但是部分為“臟“，即緩存行只在當前緩存中存在，緩存行是唯一的，但是緩存行的僅有一部分數據有效且“臟”。當該緩存行被逐出（eviction）時，必須將其與下一級緩存或內存中的數據合并，以形成完整的有效緩存行。擁有該緩存行的處理器以在不通知其它緩存的情況下修改緩存行數據。當前緩存接收到請求數據的監聽時，必須返回該緩存行數據。僅當接口支持部分緩存狀態（Partial Cache States）時，才支持此緩存行狀態。

SC（Shared Clean）：緩存行的狀態是不唯一且“干凈”，即在其它緩存中可能有該緩存行的副本，且緩存行數據可能被修改過，但是在當前緩存中是“干凈“的。當該緩存行在當前緩存中被逐出（eviction）時，當前緩存不需要將此緩存行數據寫回內存。當前緩存只有在無效（invalidate）此緩存行其它緩存中的副本，并取得此緩存行的唯一所有權后，才能修改此緩存行數據。當前緩存接收到請求數據的監聽時，不可以返回緩存行數據。

SD（Shared Dirty）：緩存行的狀態是不唯一且“臟”。其它緩存中可能有該緩存行的副本，緩存行數據被修改過。當該緩存行被逐出（eviction）時，必須寫回下一級緩存或內存。當前緩存只有在無效（invalidate）此緩存行其它緩存中的副本，并取得此緩存行的唯一所有權后，才能修改此緩存行數據。當前緩存接收到請求數據的監聽時，必須返回緩存行數據。

3.3.2 請求類型（Request Type）

CCIX協議中的請求分為以下四類：

讀請求：需要返回一個數據響應給請求者（requester）

寫請求：請求者發出數據

無數據請求：不需要返回一個數據響應給請求者

原子請求：請求者發出數據，請求不可分割

1. 讀事務（Read Transactions）：

ReadNoSnp：對不可監聽的（non-snoopable）地址區域的讀取請求。數據包含在完成響應中；數據大小取決于請求中的數據尺寸屬性（size attribute）值，最大是一條緩存行大小；接收到的數據不會被請求者緩存。

ReadOnce：對可監聽的（snoopable）地址區域的讀取請求，以獲取一致性數據快照。數據大小是一條緩存行；接收到的數據不會被請求者緩存。

ReadOnceCleanInvalid：對可監聽的地址區域的讀取請求，以獲取一致性數據快照。數據大小是一條緩存行；建議但不強制，緩存副本被置無效（invalidate）；如果被置無效的緩存備份是“臟”的，必須把此緩存行寫回到內存；接收到的數據不會被請求者緩存。

ReadOnceMakeInvlid：對可監聽的地址區域的讀取請求，以獲取一致性數據快照。數據大小是一條緩存行；建議但不強制，所有緩存副本被置無效（invalidate）；如果被置無效的緩存備份是“臟”的，無需把此緩存行寫回到內存；接收到的數據不會被請求者緩存。使用ReadOnceMakeInvalid事務可能會導致“臟”緩存行丟失，因此ReadOnceMakeInvalid的使用必須嚴格限制在已知允許丟失“臟”緩存行的情況下。

ReadUnique：對可監聽的地址區域的讀取請求，以對緩存行進行存儲。數據大小是一條緩存行；請求者將接收UC或UD狀態的數據。

ReadClean：對可監聽的地址區域的讀取請求。數據大小是一條緩存行；數據必須以“干凈”的狀態（UC或SC）提供給請求者。

ReadNotSharedDirty：對可監聽的地址區域的讀取請求。數據大小是一條緩存行；數據必須以UC或UD或SC狀態（不能是SD）提供給請求者。

ReadShared：對可監聽的地址區域的讀取請求。數據大小是一條緩存行；請求者將接收UC或UD或SC或SD狀態的數據。

2. 無數據事務（Dataless Transactions）： 顧名思義，這類事務不需要傳輸數據。

CleanUnique：請求可監聽的地址區域將狀態更改為Unique，以對緩存行執行存儲。典型用法是當請求者擁有緩存行的共享副本，并希望獲得存儲到緩存行的權限時可以用此事務。數據不包括在完成響應中；任何“臟”副本都必須寫回下一級緩存或內存。

MakeUnique：請求可監聽的地址區域以獲得緩存行的所有權，不需要數據響應。只有當請求者保證將對緩存行的所有字節進行存儲時，才會使用此請求。任何“臟”副本都必須失效，而無需寫回下一級緩存或內存。

Evict：用于指示緩存代理不再緩存“干凈”的緩存行。此事務不發送數據；緩存行不得保留在緩存中。

緩存維護操作（Cache Maintenance Operation，CMO）有助于軟件緩存管理。該協議包括以下支持CMO的無數據事務：

CleanShared：對CleanShared請求的完成響應可以確保所有緩存副本都更改為非“臟”狀態，并且任何“臟”副本都會寫回內存。完成響應中不用包含數據。

CleanSharedPersist：對CleanSharedPersist請求的完成響應可以確保所有緩存副本都更改為非“臟”狀態，并且任何“臟”緩存副本都會寫回PoP（Point of Persistence）。PoP是內存系統中的一個點，當系統電源斷開時，會保持對內存的寫入，當電源恢復時，會可靠的恢復對內存的寫入。完成響應中不用包含數據。

CleanInvalid：對CleanInvalid的完成響應可以確保所有緩存的副本都無效，并且任何“臟”副本都會寫入內存。完成響應中不用包含數據。

MakeInvalid：對MakeInvalid的完成響應可以確保所有緩存的副本都無效，并且必須丟棄任何“臟”副本。完成響應中不用包含數據。

SnpMe Variants：CleanShared、CleanSharedPersist、CleanInvalid和MakeInvalid事務都有一個SnpMe變體，后綴為[SnpMe]。SnpMe是請求者向主代理發出的指示，表明請求者尚未檢查其緩存中是否存在該行的副本，請求者指示主代理在必要時向請求者發出監聽。

3. 寫事務（Write Transactions）：

寫事務將數據從請求者移動到下一級緩存、內存或外圍設備。根據事務類型，傳輸的數據可以是一致的，也可以是非一致的。每個部分緩存行寫入事務必須明確數據中的字節。事務名稱中的Full或Ptl后綴指明了是整條緩存行還是部分緩存行。

WriteNoSnpPtl：寫部分緩存行到不可監聽（non-snoopable）的地址區域。數據最大是一條緩存行；必須明確寫入的字節和不寫入的字節。

WriteNoSnpFull：寫完整緩存行到不可監聽的地址區域。數據大小是一條緩存行；不需要指明寫入的字節，因為默認寫入全部字節。

WriteUniquePtl：寫部分緩存行到可監聽（snoopable）的地址區域。當緩存行在請求方無效（invalid）時，將數據的緩存行寫入下一級緩存或內存。

WriteUniqueFull：寫完整緩存行到可監聽的地址區域。當緩存行在請求方無效（invalid）時，將數據的緩存行寫入下一級緩存或內存。

CopyBack Transaction：回寫事務是寫事務的一個子類。回寫事務將一致的數據從緩存移動到下一級緩存或內存。回寫交易不需要snoop系統中的其它代理。

WriteBackPtl：將“臟”的部分緩存行寫回下一級緩存或內存。僅當支持部分緩存狀態時，才支持此事務。

WriteBackFull：將“臟”的完整緩存行寫回下一級緩存或內存。WriteBackFull又可以分為兩種，WriteBackFullUD和WriteBackFullSD。

WriteCleanFull：將“臟”的完整緩存行寫回下一級緩存或內存，并在緩存中保留干凈的副本。

WriteEvictFull：將唯一的“干凈”數據寫回下一級緩存。

4. 原子事務：

所謂的原子事務，指的是此事務就像原子一樣是不可分割的，要么所有操作全部完成，要么全部不執行，不存在執行部分操作的情況。在單處理器系統中，能夠在單條指令中完成的操作都可以認為是“原子操作“，因為中斷只能發生于指令之間 。但是，在對稱多處理器結構中就不同了，由于系統中有多個處理器在獨立地運行，即使能在單條指令中完成的操作也有可能受到干擾。比如，一個典型的"讀－改－寫"過程，會涉及兩次內存訪問，先把數據讀出，然后修改，最后寫回。如果沒有特殊限定，那么在這兩次內存訪問之間，有可能其它的處理器核發起內存訪問 原子事務允許請求者向互連發送帶有內存地址的事務，以及要在該內存位置上執行的操作。這種事務類型可以使操作更接近數據所在的位置。這樣，對于以原子方式執行操作和以性能高效的方式更新內存位置非常有用。

AtomicStore：發送帶有地址和要執行的原子操作的單個數據值。請求中包含數據；發出數據大小為1、2、4或8字節；目標對原子事務中提供的數據值指定的地址位置執行所需的操作；支持的操作數為8；目標返回一個沒有數據的完成響應。

AtomicLoad：發送帶有地址和要執行的原子操作的單個數據值。請求中包含數據；發出數據大小為1、2、4或8字節；目標對原子事務中提供的數據值指定的地址位置執行所需的操作；支持的操作數為8；完成響應中返回的數據大小要與請求中的數據大小一致。

AtomicSwap：發送數據值，交換值和執行地址。請求中包含數據；發出數據大小為1、2、4或8字節；目標對原子事務中提供的數據值指定的地址位置執行所需的操作；支持的操作數為1；完成響應中返回的數據大小要與請求中的數據大小一致。

AtomicCompare：發送兩個數據值（比較值和交換值）執行地址。請求中包含數據；發出數據大小為2、4、8、16或32字節；目標將地址位置的值與比較值進行比較，如果值匹配，目標會將交換值寫入尋址位置，如果值不匹配，則目標不會將交換值寫入尋址位置。目標返回地址位置的原始值，完成響應的數據大小是請求中數據大小的一半。支持的操作數為1。

SnpMe Variants：上訴原子事務都有一個SnpMe變體，以后綴名[SnpMe]區分。

下面是不同請求的操作碼（opcode）：

對于AtomicLoad和AtomicStore，ReqOp[2:0]的編碼含義為：

ReqOp[3]指示大小端。

3.3.3 請求響應

所有事務都需要有一個完成響應。它通常是結束請求事務所發送的最后一條消息。請求完成響應分為以下幾類：

讀完成：讀完成響應包括數據響應；讀完成響應還包括一個緩存狀態，指示行緩存行的狀態；讀完成中不使用字節使能功能。

無數據完成：無數據完成響應不包括數據響應；無數據完成響應也不包括緩存狀態，緩存行的狀態由請求者決定。

寫完成：寫完成響應不包括數據響應；寫完成響應也不包括緩存狀態。

以下是內存請求的響應操作碼編碼：

3.3.4 監聽請求

主代理會生成一個監聽請求，以控制緩存代理（被監聽者，也稱為Snoopee）處的緩存行狀態。監聽請求有：

SnpToAny：用于獲取緩存行副本，無需更改狀態；在被監聽端，不需要更改緩存行狀態。

SnpToC：用于確保緩存行不處于“臟”狀態，通常用于執行緩存清理操作；在被監聽端，緩存行不可以是“臟”；緩存行（如果有效）預計將更改為“干凈”狀態，即UC或SC；緩存行可以（但不要求）轉移為無效狀態。

SnpToS：用于確保緩存行不處于唯一（unique）狀態。可以確保在被監聽端，在不通知系統中的其它代理的情況下，緩存行不會被更改。當主代理允許一個“臟”緩存行副本在被監聽端是SD狀態，通常使用SnpToS，而不是SnpToSC。在被監聽端，緩存行不可以是唯一狀態；緩存行（如果有效）預計將更改為共享狀態，即SC或SD；緩存行可以（但不要求）轉移為無效狀態。

SnpToSC：用于確保緩存行不處于唯一或“臟”狀態。當主代理不允許一個“臟”緩存行副本在被監聽端，通常使用SnpToSC，而不是SnpToS。在被監聽端，緩存行不可以是唯一或“臟”狀態；緩存行（如果有效）預計將更改為SC狀態；緩存行可以（但不要求）轉移為無效狀態。

SnpToI：用于將緩存行轉移到無效狀態。通常用于當另一個代理請求對緩存行執行存儲時。

SnpMakeI：用于將緩存行轉移到無效狀態，而不會從被監聽返回任何數據，即使緩存行處于“臟”狀態。通常用于另一個代理請求對整個緩存行執行存儲時。

SnpChain：將當前監聽連接到同一數據包中較早的監聽之后。

以下是每種監聽請求的初始和最終狀態：

SnpOp編碼：

請求類型和相對應的監聽請求如下表。其中，E表示期望的監聽請求；E1表示當被監聽端允許切換到SD（SharedDirty）狀態時的期望監聽請求；E2表示當被監聽端不允許切換到SD狀態時的期望監聽請求；P表示允許的監聽請求。

3.3.5 監聽響應

監聽響應可以帶數據，也可以不帶。 監聽響應中的最終緩存狀態必須精確。被監聽者可以在發出監聽響應后進行任何合法的靜默緩存狀態轉換（Silent Cache State Transition）。 SnpRespOp編碼：

3.3.6 MiscOp編碼

下表列出了其它的雜項消息類型，包括兩類：Credited和Uncredited。所謂的雜項消息就是指這些消息既不屬于請求類型和請求響應，也不屬于監聽請求和監聽響應。 NOP，CreditGrant，CreditReturn和ProtErrReport使用雜項信息通道。Generic消息可以使用Uncredited或Credited的雜項消息，其有效負載為2到32字節，其內容由具體實現所定義。

3.3.7 協議錯誤報告

CCIX組件（如請求代理、主代理、從代理、CCIX端口或CCIX鏈路）使用ProtErrReport（PER）消息向錯誤代理（EA）報告錯誤。該消息使用編碼0011的MiscOp[3:0]，有效負載為32字節。有關CCIX協議錯誤報告（PER）的詳細信息，后面介紹。

3.3.8 請求緩存狀態轉移

請求者緩存處（讀請求）的緩存狀態轉換：

上表第一列是發出的讀請求類型，第二列是可以啟動請求的緩存行的所有允許狀態，第三列是事務完成后緩存行的允許狀態，第四列是允許的響應。可以結合讀請求類型那個章節看這個表。以ReadNoSnp為例，ReadNoSnp是對不可監聽的地址區域的讀取請求，且接收到的數據不會在請求端緩存。因此緩存行初始和最終狀態都是Invalid。 無數據請求的緩存狀態轉換：

寫請求的緩存狀態轉換：

原子請求的緩存狀態轉換：

3.3.9 被監聽（Snoopee）端狀態轉移

被監聽者在接收到監聽請求后，必須根據監聽類型的要求轉換緩存行的狀態。下表是有關每種監聽類型的初始和最終狀態的信息，以及相應的監聽響應。可以結合監聽請求那個章節看這張表。

3.3.10 靜默緩存狀態轉移

靜默緩存狀態轉換（Silent Cache State Transition）定義為緩存因內部事件而改變狀態，而不通知系統其它部分。下表是合法的靜默緩存狀態轉換。在某些情況下，可以（但不必需）發出一個事務來指示轉換已經發生。如果發出這樣的事務，則緩存狀態轉換對互連網絡可見，因此也就不被歸類為靜默轉換。

3.3.11 控制Evict和WriteEvictFull的使用

需要一種機制來控制請求代理和主代理之間的Evict（Dataless事務）和WriteEvictFull（寫事務）的使用。 每個請求代理都有兩個控制比特位，即RAEvictHintCntl和RAWriteEvictFullHintCntl，用于確定請求代理在Evict和WriteEvictFull事務方面的行為。 RAEvictHintCntl（默認值為0）：

=0，出于最佳系統性能考慮，不建議從RA發送Evict事務。

=1，出于最佳系統性能考慮，建議從RA發送Evict事務。

RAWriteEvictFullHintCntl（默認值為0）：

=0，出于最佳系統性能考慮，不建議從RA發送WriteEvictFull事務。

=1，出于最佳系統性能考慮，建議從RA發送WriteEvictFull事務。

每個主代理也有兩個比特位，HAEvictHintCap和HAWriteEvictFullHintCap，用于指示有關使用Evict和WriteEvitFull事務的首選行為。 HAEvictHintCap：

=0，出于最佳系統性能考慮，不建議向HA發送Evict事務。

=1，出于最佳系統性能考慮，建議向HA發送Evict事務。

HAWriteEvictFullHintCap：

=0，出于最佳系統性能考慮，不建議向HA發送WriteEvictFull事務。

=1，出于最佳系統性能考慮，建議向HA發送WriteEvictFull事務。

3.3.12 同時超發請求

不支持同一請求代理對同一地址位置的請求超發（outstanding），除非它們僅包括ReadNoSnp、WriteNoSnp、ReadOnce或WriteUnique的任何組合。 不支持同時向同一請求代理發送到同一地址位置的多個Snoop事務。

3.3.13 對監聽冒險的請求

當一個CopyBack請求發現對相同緩存行地址有未完成的監聽，或者反過來，一個監聽發現對相同緩存行地址有未完成的CopyBack，則會發生請求競爭。注意，如果監聽目標代理ID和請求源代理ID不相同，則不視為請求競爭。

上圖中，Chip 1中的HA向Chip 0中的RA發起了一個監聽；同一時刻Chip 0的RA向Chip 1的HA發起了一個請求（對同一地址）。圖中的帶數據的請求，可以是CopyBack：WriteBackFullUD、WriteBackFullSD、WriteCleanFullSD或WriteEvickFull。在存在多個CCIX-R、CCIX-H端口的多跳（Muliti-hop）路由中，要求該路徑中的每個端口必須包含競爭檢測邏輯，以檢測請求對監聽的競爭。 【待續】

審核編輯 ：李倩