CCIX協(xié)議層講解

3. CCIX協(xié)議層

3.4 事務(wù)結(jié)構(gòu)

3.4.1 請求事務(wù)

基于結(jié)構(gòu)的不同請求類型如下：

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

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

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

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

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

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

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

此類事務(wù)不需要CompAck

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

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

主芯片返回Comp響應(yīng)

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

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

主芯片返回Comp響應(yīng)

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

所有寫事務(wù)都使用相同的事務(wù)結(jié)構(gòu)。事務(wù)流程如下圖。

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

主芯片返回Comp響應(yīng)。

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

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

主芯片返回Comp（對應(yīng)AtomicStore）或CompData（對應(yīng)non-AtomicStore）。

3.4.2 監(jiān)聽事務(wù)

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

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

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

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

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

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

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

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

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

3.5.2 請求屬性

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

3.5.3 請求允許的內(nèi)存類型

請求允許的內(nèi)存類型包括：

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

除ReadNoSnp外的所有讀事務(wù)只能寫回。

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

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

除WriteNonP外的所有寫事務(wù)只能進行寫回。

原子事務(wù)可以寫回，Normal Non-cacheable或Device

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

在讀請求或?qū)懻埱笾校琑eqAttr字段的Size子字段決定了事務(wù)相關(guān)聯(lián)的數(shù)據(jù)字節(jié)數(shù)。Size子字段的允許值為1B、2B、4B、5 8B、16B、32B、64B、128B。讀響應(yīng)或?qū)懻埱笾邪臄?shù)據(jù)字節(jié)可以是8B、16B、32B、64B或128B。僅當(dāng)緩存行的大小配置為128B時，才允許使用128B。

當(dāng)ReqAttr字段中的Size子字段為1B、2B或4B時，讀響應(yīng)消息或?qū)懻埱笙⒅邪臄?shù)據(jù)字節(jié)數(shù)為8B。在所有其它情況下，請求的ReqAttr字段中的Size子字段與讀響應(yīng)消息或?qū)懻埱笙⒅邪臄?shù)據(jù)字節(jié)數(shù)相同。當(dāng)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 請求響應(yīng)和排序

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

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

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

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

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

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

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

3.7.1 協(xié)議信用

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

Request

Data

Snoop

Misc

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

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

3.7.2 信用交換

兩種信用交換方式:

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

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

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

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

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

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

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

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

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

【待續(xù)】

審核編輯 ：李倩