3. CCIX協(xié)議層

3.4 事務結構

3.4.1 請求事務

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

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

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

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

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

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

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

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

此類事務不需要CompAck

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

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

主芯片返回Comp響應

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

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

主芯片返回Comp響應

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

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

請求芯片發(fā)送一個寫請求（帶數(shù)據(jù)），占用一個請求信用和一個數(shù)據(jù)信用。

主芯片返回Comp響應。

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

求芯片發(fā)送一個原子請求（帶數(shù)據(jù)），占用一個請求信用和一個數(shù)據(jù)信用。

主芯片返回Comp（對應AtomicStore）或CompData（對應non-AtomicStore）。

3.4.2 監(jiān)聽事務

無數(shù)據(jù)響應的監(jiān)聽事務流程如下

主芯片發(fā)送監(jiān)聽請求，占用一個監(jiān)聽信用（snoop credit）。

被監(jiān)聽的芯片返回SnpResp，監(jiān)聽響應，包

有數(shù)據(jù)響應的監(jiān)聽事務流程如下

主芯片發(fā)出監(jiān)聽請求（除去SnpMakeI），占用一個監(jiān)聽信用。

被監(jiān)聽的芯片返回數(shù)據(jù)和響應的響應（SnpRespData或SnpRespDataPtl ）

3.5 地址，控制和數(shù)據(jù)

3.5.1 地址和數(shù)據(jù)分配

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

3.5.2 請求屬性

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

3.5.3 請求允許的內存類型

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

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

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

所有無數(shù)據(jù)事務都可以寫回

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

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

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

3.5.4數(shù)據(jù)和字節(jié)使能

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

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

WriteNoSnpPtl

WriteUniquePtl

WriteBackPtl

3.6 排序

3.6.1 多拷貝原子性（multi-copy atomicity）

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

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

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

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

3.6.2 請求響應和排序

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

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

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

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

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

3.7流量控制和協(xié)議信用

此處穿插一些關于“信用”的數(shù)據(jù)傳輸機理。如果發(fā)送方和接收方之間沒有什么握手協(xié)議的話，發(fā)送方就不知道接收方的具體情況。此時，如果接收方?jīng)]有足夠的能力接收新的數(shù)據(jù)，而發(fā)送方依然源源不斷的發(fā)送數(shù)據(jù)，那么就很可能造成數(shù)據(jù)的丟失。因此，接收方需要一定的機制來控制數(shù)據(jù)流量。最直觀的辦法，就是當接收方不能接收新的數(shù)據(jù)時，要及時告知發(fā)送方，發(fā)送方應根據(jù)接收方的狀態(tài)調整發(fā)送數(shù)據(jù)，這就是常說“反壓（Back Pressure）”機制。 在簡單的SoC設計中，可以通過總線實現(xiàn)接收方的“反壓”，比如在APB總線中，從機（Slave）可以通過驅動ready信號來與主機（Master）共同控制數(shù)據(jù)傳輸。對于復雜的SoC設計，通過總線方式“反壓”可能就不適合了，需要其它新的機制?；谛庞玫膫鬏斄髁靠刂凭褪瞧渲兄弧Ｆ浠驹硎?，在發(fā)送方和接收方事先協(xié)調好一組“信用”值，發(fā)送方每發(fā)一次數(shù)據(jù)需要占用一個或幾個“信用”，如果發(fā)送方的“信用”耗盡，就不能再發(fā)送新的數(shù)據(jù)，必須等待足夠的“信用”；接收方每處理完一筆發(fā)送方的數(shù)據(jù)，返回一個或者幾個“信用”給發(fā)送方，發(fā)送方得到新的“信用”以后就可以繼續(xù)發(fā)送數(shù)據(jù)了。 關于基于信用的流量控制，有很多文章，具體實現(xiàn)也不盡相同，這里就不再展開了。

3.7.1 協(xié)議信用

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

Request

Data

Snoop

Misc

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

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

3.7.2 信用交換

兩種信用交換方式:

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

包頭內信用授權。數(shù)據(jù)包頭信用授權使用數(shù)據(jù)包頭中6-bit的MsgCredit字段。

信用交換的規(guī)則：

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

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

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

信用交換信息的發(fā)送速率沒有上限。

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

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

【待續(xù)】

審核編輯 ：李倩