3. CCIX協議層

3.4 事務結構

3.4.1 請求事務

基于結構的不同請求類型如下：

全一致性讀事務，包括：ReadUnique，ReadClean, ReadNotSharedDirty，ReadShared。其事務流程如下圖。

請求芯片發出一個讀請求事務，占用一個請求信用(request credit)。

主芯片返回讀數據和相應的事務響應(使用CompData操作碼)。

請求者發送確認響應，確認事務完成(使用CompAck操作碼)。

非一致性或IO一致性讀事務，包括：ReadNoSnp，ReadOnce，ReadOnceCleanInvalid，ReadOnceMakeInvalid。其事務流程如下圖。

請求芯片發出一個讀請求事務，占用一個請求信用(request credit)。

主芯片返回讀數據和相應的事務響應(使用CompData操作碼)。

此類事務不需要CompAck

無CompAck的無數據事務，包括：CleanShared，CleanSharedPersist，CleanInvalid，MakeInvalid，Evict. 其事務流程如下圖。

請求芯片發出一個讀請求事務，占用一個請求信用(request credit)。

主芯片返回Comp響應

有CompAck的無數據事務，包括：CleanUnique，MakeUnique。事務流程如下圖。

請求芯片發出一個讀請求事務，占用一個請求信用。

主芯片返回Comp響應

請求者發送確認響應，確認事務完成(使用CompAck操作碼)。

所有寫事務都使用相同的事務結構。事務流程如下圖。

請求芯片發送一個寫請求(帶數據)，占用一個請求信用和一個數據信用。

主芯片返回Comp響應。

原子事務基于Comp響應，分成兩類，一類是AtomicStore(無數據)，另一類是AtomicLoad，AtomicSwap，AtomicCompare(有數據)。事務流程如下圖。

求芯片發送一個原子請求(帶數據)，占用一個請求信用和一個數據信用。

主芯片返回Comp(對應AtomicStore)或CompData(對應non-AtomicStore)。

3.4.2 監聽事務

無數據響應的監聽事務流程如下

主芯片發送監聽請求，占用一個監聽信用(snoop credit)。

被監聽的芯片返回SnpResp，監聽響應，包

有數據響應的監聽事務流程如下

主芯片發出監聽請求(除去SnpMakeI)，占用一個監聽信用。

被監聽的芯片返回數據和響應的響應(SnpRespData或SnpRespDataPtl )

3.5 地址，控制和數據

3.5.1 地址和數據分配

對于讀、無數據、寫和原子事務，使用Addr字段和NonSec比特位訪問內存位置。對于訪問小于一個緩存行大小的ReadNoSnp、WriteNoSNPTL、WriteUniquePtl和原子事務，如果Addr[5:0]不全為零，則需要包含低階地址位的擴展字段。如果Addr[5:0]全部為零，則允許(但不要求)使用擴展字段。原子事務中的地址必須與操作數大小對齊。對于監聽請求，Addr字段和NonSec指向可以被監聽的地址。這兩個字段足以唯一標識監聽要訪問的緩存行。

3.5.2 請求屬性

請求屬性表示請求數據的大小、內存類型及其屬性。內存類型可以是設備(device)或普通(normal)。關于這兩種類型可以參考以前的文章。

3.5.3 請求允許的內存類型

請求允許的內存類型包括：

ReadNoSnp/WriteNoSnp可以是Normal Non-cacheable或Device

除ReadNoSnp外的所有讀事務只能寫回。

所有無數據事務都可以寫回

CleanShared、CleanSharedPersist、CleanInvalid和MakeInvalid的無數據事務也可以是Normal Non-cacheable或Device。

除WriteNonP外的所有寫事務只能進行寫回。

原子事務可以寫回，Normal Non-cacheable或Device

3.5.4 數據和字節使能

在讀請求或寫請求中，ReqAttr字段的Size子字段決定了事務相關聯的數據字節數。Size子字段的允許值為1B、2B、4B、5 8B、16B、32B、64B、128B。讀響應或寫請求中包含的數據字節可以是8B、16B、32B、64B或128B。僅當緩存行的大小配置為128B時，才允許使用128B。

當ReqAttr字段中的Size子字段為1B、2B或4B時，讀響應消息或寫請求消息中包含的數據字節數為8B。在所有其它情況下，請求的ReqAttr字段中的Size子字段與讀響應消息或寫請求消息中包含的數據字節數相同。當ReqAttr字段中的Size子字段為1B、2B或4B時，請求數據在消息中的位置由請求中的Address字段(Addr)確定。對于以下的寫請求，可以使用字節使能：

WriteNoSnpPtl

WriteUniquePtl

WriteBackPtl

3.6 排序

3.6.1 多拷貝原子性(multi-copy atomicity)

CCIX要求多拷貝原子性。所有組件都必須確保寫請求是多拷貝原子的。如果滿足以下兩個條件，則寫請求為多拷貝原子：

對同一位置的所有寫入都是序列化的，也就是說，所有請求者都會以相同的順序觀察到所有寫操作，盡管有些請求者可能不會觀察到所有寫入。

在所有請求者觀察到寫操作之前，對此位置的讀操作不會得到寫操作的值。

其實以上的要求，就是要確保存儲一致性。在CCIX規范中，如果兩個緩存行地址和非安全屬性相同，則認為這兩個地址是相同的。

3.6.2 請求響應和排序

為了確保事務的先后順序，無論是來自相同代理還是不同代理的Comp和CompData響應要遵循如下的規則：

對于Normal non-cacheable或Device的讀事務和原子事務，CompData響應可確保該事務可被任何代理在相同端點地址范圍內的后續事務觀察到。端點地址范圍的大小由實現定義。

對于WriteBack位置的讀取和原子事務，CompData響應保證該事務可被任何代理到同一位置的后續事務觀察到。

對于Device-nRnE或Device-nRE位置的寫事務、無數據事務和原子事務，Comp響應保證該事務可被任何代理在同一端點地址范圍內的后續事務觀察到。端點地址范圍的大小取決于具體實現。

對于WriteBack位置的寫事務、無數據事務和原子事務。Comp響應可確保事務可被任何代理到同一位置的后續事務觀察到。

3.7 流量控制和協議信用

此處穿插一些關于“信用”的數據傳輸機理。如果發送方和接收方之間沒有什么握手協議的話，發送方就不知道接收方的具體情況。此時，如果接收方沒有足夠的能力接收新的數據，而發送方依然源源不斷的發送數據，那么就很可能造成數據的丟失。因此，接收方需要一定的機制來控制數據流量。最直觀的辦法，就是當接收方不能接收新的數據時，要及時告知發送方，發送方應根據接收方的狀態調整發送數據，這就是常說“反壓(Back Pressure)”機制。在簡單的SoC設計中，可以通過總線實現接收方的“反壓”，比如在APB總線中，從機(Slave)可以通過驅動ready信號來與主機(Master)共同控制數據傳輸。對于復雜的SoC設計，通過總線方式“反壓”可能就不適合了，需要其它新的機制。基于信用的傳輸流量控制就是其中之一。其基本原理是，在發送方和接收方事先協調好一組“信用”值，發送方每發一次數據需要占用一個或幾個“信用”，如果發送方的“信用”耗盡，就不能再發送新的數據，必須等待足夠的“信用”;接收方每處理完一筆發送方的數據，返回一個或者幾個“信用”給發送方，發送方得到新的“信用”以后就可以繼續發送數據了。關于基于信用的流量控制，有很多文章，具體實現也不盡相同，這里就不再展開了。

3.7.1 協議信用

定義了四種信用類型來管理消息流：

Request

Data

Snoop

Misc

消息的接收者必須授予信用，也就是說，向它有鏈接的每個發送者芯片發送信用。對于請求、數據和Snoop消息信用，信用的授予是通過其它消息或明確的信用交換機制進行的。對于雜項消息信用，信用的授予僅通過明確的信用交換機制，或通過使用credited雜項消息中的MiscCredit字段。

只有當發送方收到目標芯片的請求信用時，才能發送non-write或non-atomic請求。只有當發送方從接收方收到請求信用和數據信用時，才能發送寫請求或原子請求。只有當發送方從接收方收到snoop信用時，才能發送snoop請求。響應不需要任何明確的信用交換，所有響應都必須被接受。只有當適當數量的雜項信息信用可用時，才能發送credited雜項信息。

3.7.2 信用交換

兩種信用交換方式:

用于信用交換的獨立消息，信用授予和信用返還消息。這種方式使用專用消息交換信用。消息格式允許信用授予和信用返還。在單個消息中的信用交換，必須是所有信用授予或所有信用返還，不允許混合使用這兩種類型。

包頭內信用授權。數據包頭信用授權使用數據包頭中6-bit的MsgCredit字段。

信用交換的規則：

對于每種信用類型，每個獨立信用交換報文中可發送的最大信用數為255。

發送超過255個信用需要使用額外的信息。

獨立的信用交換信息不需要發送任何形式的信用。

信用交換信息的發送速率沒有上限。

允許單個數據包同時包含“數據包頭信用授權”，和一條或多條“獨立信用交換消息”。

每個信用類型最多可授予1023個信用

審核編輯：湯梓紅