全方位的Arm AMBA 協(xié)議層介紹

本文選自極術(shù)專欄Arm AMBA 協(xié)議集的文章，文章主要從傳輸通道和相關(guān)重要域段、各transaction類型的傳輸結(jié)構(gòu)、傳輸響應(yīng)類型、cache狀態(tài)轉(zhuǎn)換等角度對協(xié)議層進行全方位的介紹。

一、傳輸通道和域段

1.1傳輸通道

協(xié)議節(jié)點之間的通訊是基于通道channels進行的，表1為RN和SN節(jié)點的通道名字和功能：

表1

1.2域段

transaction是有許多不同的packets組成，而且transaction結(jié)構(gòu)隨著packets中的域段不同也可能不同。只有request channel和snoop channel中的某些域段可能會影響transaction structure，Response packet和Data pacet不會影響transaction structure，域段上攜帶有packet的信息。具體每個通道包含的域段的含義可以查下CHI issueC 表2-2至2-5手冊，不仔細列出了，只是闡述總結(jié)性的知識點。

1.2.1ID域段

Target Identifier(TgtID)，Source Identifier(ScrID)：用于packet在ICN上的路由；

Transaction Identifier(TxnID)，Data Buffer Identifier(DBID)，Return Transaction Identifier(ReturnTxnID)，F(xiàn)orward Transaction Identifier(FwdTxnID)用于關(guān)聯(lián)同一個transaction的所有packets；

Data Identifier(DataID),Critical Chunk Identifier(CCID)：用于同一個transaction內(nèi)表示特定的data packets；

Logical Process Identifier(LPID)，Stash Logical Processor Identifier(StashLPID)：用于同一個Requester內(nèi)表示特定的處理器單元；

Stash Node Identifier(StashNID)：該域段用于標識Stash的目的節(jié)點；

Return Node Identifier(ReturnNID)，F(xiàn)orward Node Identifier(FwdNID)：這些域表示了返回數(shù)據(jù)響應(yīng)應(yīng)該送到的節(jié)點；

Home Node Identifier：該域標識了CompAck響應(yīng)應(yīng)該送到的節(jié)點；

在每個packer中使用到的域段也一樣，如下：

Request packet：TgtID，SrcID，TxnID，LPID，StashNID，StashLPID，ReturnNID，ReturnTxnID；

Response packet：TgtID，SrcID，TxnID，DBID；

Data packet：TgtID，SrcID，TxnID，HomeNID，DBID；

Snoop packet：SrcID，TxnID，F(xiàn)wdNID，F(xiàn)wdTxnID，StashLPID；

在看transaction Identifier field flow時，記得遵循以下規(guī)定，就很easy了：

1、所有的帶有相同顏色的域段的值是一樣的；
2、用箭頭表明后續(xù)packets是由哪個產(chǎn)生的；
3、包含*的表示第一次產(chǎn)生，由當前agent產(chǎn)生該域的原始值；
4、*帶圓括號()的表示該域是固定值，典型如Requester發(fā)送packets的SrcID，packets到達Completer的TgtID；
5、被劃掉的域段表示該域段無效；
6、可以被ICN remapped的TgtID要標識上字母R；
7、任何和當前傳輸不相關(guān)的域段在CHI協(xié)議域段流程圖上省略了； 具體的Read transactions、Write transactions、Dataless transactions和DVMOp transaction等transactions的域段傳輸流程圖可以看下issueC的圖2-24至2-33，里面有詳細的各個域段轉(zhuǎn)換說明；

具體的Read transactions、Write transactions、Dataless transactions和DVMOp transaction等transactions的域段傳輸流程圖可以看下issueC的圖2-24至2-33，里面有詳細的各個域段轉(zhuǎn)換說明；

這里補充下LPID這個域段的一些知識：

CHI協(xié)議在Request transaction里定義了一個LPID，如果在一個Requester內(nèi)部包含多個logical processes，該域段用于標識唯一Logical process。在以下transactions中，LPID必須設(shè)置為正確的值：

For any Non-snoopable Non-cacheable or Device acess：ReadNoSnp、WriteNoSnp；

For Exclusive accesses，that can be one of the following transaction types：ReadClean、ReadShared、ReadNotSharedDirty、CleanUnique、ReadNoSnp、WriteNoSnp；

除了以上的操作，其他transaction的LPID域也可以用于標識發(fā)送transaction的original logical processor，但是該功能在CHI中是可選的。

1.2.2ID域段

Packet包含了其他的定義Transactions行為的屬性信息，這些屬性通過Packet域段傳遞到總線上，總線解析這些信息并采取相對應(yīng)的操作。這些信息有：address、Secure bit、memory attributes、likely shared、snoop attributes、Do not transition to SD、data formatting。

1.2.2.1Address

CHI協(xié)議支持

Physical Address(PA) of 44 to 52 bits, in one bit increments

Virtual Address(VA) of 49 to 53 bits

對于REQ和SNP packet的地址域為：

REQ channel：Addr[(MPA-1):0]

SNP channel：Addr[(MPA-1):3]

MPA是PA的最大值；對于REQ packet的地址位寬為44bit-52bit，SNP packet的地址位寬為41bit-49bit，地址信息在不同的message類型中有不同的用途，如下：

對于Read、PrefetchTgt、Datelss、Write、Atomic transactions，REQ的addr域就是要訪問memory的地址信息；

對于Snoop request，除了SnpDVMOp，Addr[(43-51):6]用于snoop cacheline；Addr[5:4]標識transaction訪問的critical chunk，CHI協(xié)議建議被snoop的cache data以wrap形式且最先critical chunk的形式返回；Addr[3]不用；

對于DVMOp操作，Addr信息是用于攜帶DVM操作的相關(guān)信息；

PCrdRetrun transaction的地址域必須為0；

1.2.2.2Address

Request transaction可以定義Secure bit來指定該操作安全和非安全；對于Snoopable transactions，secure field可以認為是附加的地址bit，因此相當于定義了兩份地址空間：安全地址空間和非安全地址空間，硬件一致性沒法管理安全和非安全地址空間的一致性，因此使用時要正確處理好。Secure field可以在以下操作中使用：

所有Read、Dataless、Write、Atomic transactionPrefetchTgt transaction

在DVMOp和PCrdRetrun中不用，且必須為0

1.2.2.3Address

Memory Attributes(MemAttr)是由Early Write Acknowledge(EWA)，Device，Cacheable和Allocate組成的。

1、EWA

EWA用于指示寫完成信號從哪個節(jié)點返回。如果EWA置位，寫完成信號可以來自中間節(jié)點(如：HN)，也可以來自endpoint(最終節(jié)點)，來自中間節(jié)點的完成信號必須提供同樣的Comp響應(yīng)來保證；如果EWA不置位，寫完成響應(yīng)必須來自最終節(jié)點；

注意：如果不實現(xiàn)EWA功能的話，那么寫完成響應(yīng)必須來自endpoint。EWA是否置位根據(jù)transaction分類如下：

ReadNoSnpSep、ReadNoSnp、WriteNoSnp、CMO、Atomic transaction可以采用任意值；

除了ReadNoSnpSep、ReadNoSnp、CMO、WriteNoSnp之外的所有Read、* Dataless和Write transaction必須將EWA置位；

在DVMOp或PCrdRetrun transaction中不使用，tie為0；

在PrefetchTgt中不使用，為任意值；

2、Device

Device屬性指示訪問的memory屬性是Device還是Normal。

Device memory type：

Device memory type空間必須用于地址相關(guān)性的memory空間，當然用于地址不相關(guān)性的空間也允許。

訪問Device type memory空間的transaction有如下要求：

Read transaction不能讀到比要求更多的數(shù)據(jù)；

PrefetchTgt不能訪問Device memory空間；

讀數(shù)據(jù)必須來自endpoint，不能來自同地址write操作的中間節(jié)點；

不能將多筆訪問不同地址的請求組合成一筆，也不能將訪問同一個地址的多個不同請求組合成一筆；

寫操作不能merged；

訪問Device memory的寫操作的完成信號是來自中間節(jié)點的話，需要即使使寫數(shù)據(jù)對endpoint節(jié)點可見。

訪問Device memory的transaction必須使用以下類型：

必須使用ReadNoSnp操作去讀Device memory空間；

必須使用WriteNoSnp或WriteNoSnpPtl去訪問Device memory空間；

CMO和Atomic操作允許訪問Device空間；

PrefetchTgt不允許訪問Device memory空間，該bit不用且可以為任意值；

Normal memory type：

Normal memory type空間用于地址不相關(guān)的memory空間，不能用于地址相關(guān)的memory空間。

訪問Normal memory空間在prefetching或forwarding上沒有和Device type memory空間同樣的約束：

EWA的讀數(shù)據(jù)可以來自同地址write操作的中間節(jié)點；

寫操作可以merged；

任何Read、Dataless、Write、PrefetchTgt、Atomictransaction類型都可以去訪問Normal memory空間。具體使用的transaction type要完成的memory操作和Snoopable屬性。

3、Cacheable

Cacheable屬性用于指示一筆transaction是否必須執(zhí)行cache查找：

當Cacheable置位時，transaction必須執(zhí)行cache查找；

當Cacheable沒置位時，transaction必須訪問最終節(jié)點；

Cacheable attribute的值有如下要求：

對于任何的Device memory transaction，必須不置位；

除了ReadNoSnpSep和ReadNoSnp，任何Read transaction必須置位；

除了CMO操作，任何Dataless操作必須置位；

除了WriteNoSnp和WriteNoSnpPtl，任何write transaction都必須置位；

在ReadNoSnpSep、ReadNoSnp、WriteNoSnpFull、WriteNoSnpPtl訪問Normal memory空間時，可以為任何值；

在CMO和Atomic transactions中可以為任意值；

在DVMOp和PCrdRetrun transaction中必須為0；

在PrefetchTgt中不會用，可以為任意值；

注意：如果一筆transaction的Cacheable可以設(shè)置為任意值，通常情況下是有page table attributes決定的。

4、Allocate

Allocate attribute是一種cache緩存分配指示，它指示一筆transaction是否推薦分配cache緩存，具體如下：

如果Allocate置位，出于性能考慮，建議該筆transaction的數(shù)據(jù)應(yīng)該被分配到cache中，但也可以不分配；
如果Allocate不置位，出于性能考慮，建議該筆transaction的數(shù)據(jù)不應(yīng)該被分配到cache中，但其實也可以分配的；
Allocate attribute值有如下要求：
可以在任意Cacheable置位的transaction中置位；
WriteEvictFull操作必須置位；如果WriteEvictFull的Allocate沒有置位，RN可以將其轉(zhuǎn)換為Evict操作；
對于Device memory transaction必須不能置位；
對于Normal Non-cacheable memory transaction中不能置位；
在DVMOp、PCrdRetrun和Evict操作中不使用，必須設(shè)置為0；
在PrefetchTgt中不使用，可以設(shè)置為任意值；

5、Propagation of Attr

MemAttr屬性在一筆transaction從HN發(fā)往SN時必須要保留，有一種情況除外：

當知道downstream memory是Normal類型，那Device域值要設(shè)置為0來知識Normal類型；
SnpAttr attribute bit值在HN到SN中不需要保留，且必須設(shè)置為0；

由于HN的Prefetch預(yù)取或者SystemCache的eviction操作下產(chǎn)生的ReadNoSnp和WriteNoSnp transaction，相關(guān)屬性設(shè)置如下：

MemAttr中的EWA、Cacheable、Allocate必須全部設(shè)置為1；
Device屬性必須設(shè)置為0指示是Normal type；
SnpAttr屬性必須設(shè)置為0指示是Non-snoopable；

1.2.2.4Transaction attribute combinations

表1列出了合法的MemAttr、SnpAttr和Order域組合，并且等價于相應(yīng)的ARM memory type。表1 Legal combinations of MemAttr, SnpAttr, and Order field values

對于表1所示的每種Memory type的具體規(guī)格下面將進行闡述：

1、Device nRnE

Device nRnE memory type有如下行為：

寫響應(yīng)必須從最終節(jié)點獲得；
讀數(shù)據(jù)必須從最終節(jié)點獲得；
讀數(shù)據(jù)不能得到比預(yù)期要求的更多；
讀操作不能被預(yù)取；
寫操作不能被merged；
寫操作不能寫大于原始transaction的地址范圍；
來自同源的所有讀和寫transaction去往同一個endpoint必須要保序；

2、Device nRE

Device nRE memory type的行為和Device nRnE memory一致，除了：

寫響應(yīng)可以從中間節(jié)點獲得；

3、Device RE

Deivce RE memory type的行為和Device nRE memory一致，除了：

來自同一個源的讀和寫transactions發(fā)往同一個endpoint不需要保序；
來自同一個源的讀和寫transactions發(fā)往有交疊地址的需要保序；

4、Normal Non-cacheable Non-bufferable

Normal Non-cacheable Non-bufferable memory type的行為如下：

寫響應(yīng)必須來自最終節(jié)點；
讀數(shù)據(jù)必須來自最終節(jié)點；
寫操作可以被merged；
同一個源的讀和寫transactions發(fā)往有交疊地址的需要保序；

5、Normal Non-cacheable Bufferable

Normal Non-cacheable Bufferable memory type的行為如下：

寫響應(yīng)可以從中間節(jié)點返回；
寫transaction必須對最終節(jié)點及時可見，但沒有機制能夠決定何時寫transaction可以被最終節(jié)點可見；
讀數(shù)據(jù)可以從幾個地方獲取：a. 最終節(jié)點；b. 正在發(fā)往最終節(jié)點的寫傳輸，如果數(shù)據(jù)時從寫傳輸中獲得，那么它必須來自最近的寫傳輸，而且數(shù)據(jù)不能被后期讀緩存起來；
寫操作可以被merged；
同一個源的讀和寫transactions發(fā)往有交疊地址的需要保序；

6、Write-back No-allocate

Write-back No-allocate memory type的行為如下：

寫響應(yīng)可以從中間節(jié)點返回；
寫傳輸不要求對最終節(jié)點可見；
讀數(shù)據(jù)可以從中間cahce獲得；
讀操作可以prefetch預(yù)??；
寫可以被merged；
讀和寫transaction需要查找cache；
同一個源的讀和寫transactions發(fā)往有交疊地址的需要保序；
No-allocated attribute只是一種cache分配暗示，為了性能考慮，建議不緩存到cache中，但是也可以被allocate到cache中；

7、Write-back Allocate

Write-back Allocatememory type的行為和Write-back No-allocate memory一樣，除了該種memory為了性能考慮，是建議緩存數(shù)據(jù)，但其實也可以不緩存；

1.2.2.5Likely Shared

LikelyShared是一種cache分配指示。在置位時指示requested data可能在其它RN節(jié)點中也共享著，只是為了性能考慮的一種指示作用；
LikeShared的置位規(guī)則如下：

這幾種操作可以置位：ReadClean、ReadNotSharedDirty、ReadShared、StashOnceUnique、StashOnceShared、WriteUniquePtl、WriteUniqueFull、WriteUniquePtlStash、WriteUniqueFullStash、WriteBackFull、WriteCleanFull、WriteEvictFull；
其它的Read和Write操作中不能置位；
其它的Dataless和Atomic操作中不能置位；
在DVMOp和PCrdRetrun transaction中沒有用，tie 0；
在PrefetchTgt transaction中沒有用，可以為任意值；

1.2.2.6Snoop Attribute

Snoop Attribute(SnpAttr)指示一筆transaction是否需要snoop，有Non-snoopable和Snoopable兩種，不同命令類型的snoop屬性如表2所示。

表2 Snoop attributes for the different transaction types

不管原始Request發(fā)送HN的SnpAttr域為何值，從HN發(fā)送SN的CMO、ReadNoSnpSep和ReadNoSnp的SnpAttr域值必須設(shè)置為0。

注意：對于可以取多個SnpAttr值的transaction，SnpAttr通常是由page table(頁表) attribute決定的。

1.2.2.7Do not transition to SD

Do not transition to SD是non-invalidating snoop的一種指示符，它指定被snoop的RN在snoop之后不能將cache狀態(tài)變?yōu)镾D態(tài)；

在以下幾種Snoop requests中可以根據(jù)場景使用：SnpCleanFwd、SnpClean、SnpNotSharedDirtyFwd、SnpNotSharedDirty、SnpSharedFwd、SnpShared；

在以下幾種Snoop requests中該域段必須設(shè)置為1：SnpUniqueFwd、SnpUnique、SnpCleanShared、SnpCleanInvalid、SnpMakeInvalid；

在以下幾種Snoop requests中可以為任意值，且被snoop的RN要忽略這些值：SnpOnceFwd、SnpOnce；

除了以上這些snoop requests，其它snoop requests沒有用到；

Do not transition to SD是通過SNP packet的DoNotDataPull域段體現(xiàn)出來的，如果被snoop的RN已經(jīng)是SD態(tài)，DoNotGoToSD=1，那么它必須放棄SD態(tài)；

1.2.2.8Mismatched Memory attributes

CHI協(xié)議允許兩個不同agents在同一個時間點，采用不匹配的MemAttr或SnpAttr memory attribute訪問相同的地址空間，這種情況可以認為是software protocol error，會導致一致性失效和數(shù)據(jù)值的損壞。CHI協(xié)議要求在software protocol error發(fā)生時不存在死鎖情況，且transaction仍可以進行。

使用mismatched memory attributes會導致RN-F正在進行ReadNoSnp或WriteNoSnp操作時，收到同地址的Snoop transaction，在這種情況下，Snoop transaction和RN-F已經(jīng)發(fā)送的transaction之間的順序是不確定的；

對于訪問一個4KB memory region的software protocol error不能導致其它4KB memory region的數(shù)據(jù)損壞；對于位于Normal memroy區(qū)域的，使用恰當?shù)膕oftware CMO操作可以使memory區(qū)間返回到一個確定的狀態(tài)。

1.2.2.9Data formatting

Read、Write、Atomic transactions和Snoop responses with data都有data payload。對于不同組合的address、transaction size、memory type，本節(jié)講述數(shù)據(jù)對齊規(guī)則和訪問的data bytes。

1、Data size

Size域段結(jié)合其它域段可以決定多少訪問多少bytes，表3為不同Size域段對應(yīng)的Byte數(shù)，Snoop transactions不包含Size域段，所有的snoop data傳輸都是64 Bytes。

表3 Size field value encoding

2、Bytes access in memory

MemAttr[1]域決定memory type是Device或Normal，對于不同memory type，訪問得到的byte數(shù)不一樣，具體如下：

2-a、Normal Memory

Normal memory type的transactions訪問的byte數(shù)量取決于Size域，數(shù)據(jù)時從Aligned_Address(nearest Size boundary)到下一個Size boundary。計算方式為：
Start_Address = Addr field value；
Number_Bytes = 2^Size field value；
INT(x) = Rounded down integer value of x；（即x向下取整）
Aligned_Address = (INT(Start_Address/Number_Bytes)) x Number_Bytes；
The Bytes accessed are from (Aligned_Address) to (Aligned_Address+Number_Bytes) -1；

Device

2-b Device

Device memory type的transaction訪問的byte數(shù)量是從transaction address到next Size boundary，即the bytes accessed are from (Start_Address) to (Aligned_Address + Number_Bytes) - 1；
對于Device區(qū)間的寫操作，Byte enables必須只對訪問的bytes置位；

3、Byte Enables

Byte Enables也簡稱為BE，與Write transactions和Snoop response with Data一起傳輸；

對于Write transactions，BE置位意味著相應(yīng)data byte有效，且數(shù)據(jù)必須更新到memory或cache，BE不置位意味著相應(yīng)data byte無效，且數(shù)據(jù)不能更新到memory或cache。
在Write Data和Snoop response Data中，BE無效必須設(shè)置相應(yīng)byte value為0；
如果RN在發(fā)request和data之間，有snoop請求過來，將Dirty data snoop 走了，那么CopyBackWrData_I packet將會作為Data Response發(fā)送給HN，告知HN說Copyback

request的Copyback取消了，RN必須將CopyBackWrData_I packet的所有BE值置為0。如果WriteUniquePtl、WriteUniquePtlStash、WriteNoSnpPtl被取消掉，RN也必須將WriteDataCancel的所有BE值設(shè)置為0；
除了write data是CopyBackWrData_I packet，以下Write transactions在數(shù)據(jù)傳輸時必須將全部BE設(shè)置為1：

WriteNoSnpFull

CopyBack：WriteBackFull、WriteCleanFull、WriteEvictFull

WriteUniqueFull、WriteUniqueFullStash

對于以下Write transactions允許BE以任意組合，包括全部有效或全部無效：

WriteBackPtl

WriteUniquePtl、WriteUniquePtlStash

對于WriteNoSnpPtl transaction，有以下約束：

如果訪問的是Normal memory，BE可以任意組合，包括全部有效或全部無效；

如果訪問的是Device memory，有效的BE必須在高于或等于transaction中指定的address。在address之上的任意BE組合都允許，包括全部有效或全部無效；

對于所有的Write transaction，如果BE不在Addr和Size指定的data窗口內(nèi)，則必須為0；

對于Atomic transaction，如果BE不在以下Addr和Size指定的data窗口內(nèi)，則必須為0：

如果Addr與Size對齊，Data window等于[Addr:(Addr+Size-1)]；

如果Addr不與Size對齊，Data window等于[(Addr-Size/2):(Addr+Size/2 -1)]；

對于Atomic transaction，在Data window內(nèi)的所有的data的BE都必須有效；

對于Snoop Responses with data使用SnpRespData opcode時，所有的BE都必須有效；

對于Snoop Responses with data使用SnpRespDataPtl opcode時，任意組合的BE都可以，包括全部有效或全部無效；

4、Critical chunk first wrap order

Data的發(fā)送者允許但不要求發(fā)送一個transaction里的每個獨立Data packet以critical chunk first wrap order。接口屬性CCF_Wrap_Order定義了Sender的能力以及Receiver接收的保證：

Number of bytes

Data bus width

每個packet的byte數(shù)取決于：

Data bus width

CHI協(xié)議支持以下的data bus width：

128-bit

256-bit

512-bit

DataID和CCID用于標識一個transaction內(nèi)的packet，如如果一個transaction的byte數(shù)為16通常用一個packet就可以傳輸完，DataID域的值必須等于Addr[5:4]，因為DataID域代表一個packet里最低地址byte的Addr[5:4]。表3為DataID在不同data bus widths下的值。
表4 DataID and the bytes within a packet for different data widths

在一個data packet內(nèi)，所有byte都位于他們原始byte位置，即使只有少量data bytes需要在data bus上傳輸。
對于訪問Device空間的transaction中data packets的數(shù)目與transaction中的address無關(guān)，需要的data packets數(shù)目只取決于Size域和data bus width。
CCID域用于標識一個transaction request中最關(guān)鍵的data butes，CCID域必須等于原始請求的Addr[5:4]值，一個包含多個data packets的transaction中，所有的data packets的CCID值必須全部一樣；CCID的作用是：如果多個data packet在ICN內(nèi)被reorder了，那么可以用DataID和CCID相匹配，如果相等就是第一個關(guān)鍵packet。至于用幾bit去匹配取決于data bus width：如果是128bit的data bus，CCID和DataID必須全部匹配；如果是256bit的data bus，那只需要匹配CCID和DataID的最高位；

5、Data packetization

對于帶data的每個transaction，data bytes可以使用多個packets傳輸，packets的個數(shù)取決于：

CCF_Wrap_Order at the Sender：True，Sender表示其有能力以critical chunk first wrap order發(fā)送data packets；False，Sender表示其沒有能力以critical chunk first wrap order發(fā)送data packets；

CCF_Wrap_Order at the ICN：True，ICN保證其有能力按接收順序保持一個transaction內(nèi)Data packets的順序；False，ICN不保證其有能力按接收順序保持一個transaction內(nèi)Data packets的順序；

CCF_Wrap_Order at the Receiver that is not an ICN：True，Receiver要求data packets以critical chunk first wrap order被接收，即要送來的數(shù)據(jù)就是critical chunk first wrap order；False，Receiver不要求data packets以critical chunk first wrap order被接收；

注意：在設(shè)計時，CCF_Wrap_Order參數(shù)可以幫助一個組件判斷是否需要以critical chunk first wrap order形式發(fā)送Data。例如：如果組件知道自己連接到out-of-order總線，那么它可以通過不支持以critical chunk first wrap order形式發(fā)送Data來簡化它的data packet path。如果ICN支持CCF_Wrap_Order屬性，那么RN以critical chunk first wrap order發(fā)送data packets，receiver(SN)就可以以critical chunk first來接收數(shù)據(jù)，這樣可以優(yōu)化latency。

Wrap order按如下定義：
Start_Address = Addr；
Number_Bytes = 2^Size；
INT(x) = Rounded down integer value of x；
Aligned_Address = (INT(Start_Address/Number_Bytes)) x Number_Bytes；
Lower_Wrap_Boundary = Aligned_Address；
Upper_Wrap_Boundary = Aligned_Address + Number_Bytes -1；
為了保持wrap order，order順序如下：
a. 第一筆data packet必須對應(yīng)于Start_Address所指定的data bytes；
b. 接下一筆必須對應(yīng)于地址遞增方向的data bytes，直到Upper_Wrap_Boundary；
c. 接下一筆必須對應(yīng)于Lower_Wrap_Boundary；
d. 接下一筆必須對應(yīng)于地址遞增方向的data bytes，直到Start_Address；

對于Data transfer examples可以參見CHI-issueC 122頁，這里不仔細說明。

1.2.2.10Data formatting

為了防止request transactions將REQ通道堵住，CHI協(xié)議提供了一種request retry機制，當Completer無法接收request transaction時，可以發(fā)RetryAck響應(yīng)。除了PrefetchTgt和PCrdRetrun，其它命令都可以被Retry。

除了PrefetchTgt，Requester要求保留住所有已發(fā)送的request，直到收到request對應(yīng)的完成響應(yīng)或者retryack指示后續(xù)再發(fā)送，為了達到該要求，除了PrefetchTgt，transaction在第一次發(fā)送時AllowRetry需要置位，即允許retry。

Completer通常在沒有資源和沒有足夠存儲空間來存放當前的request transaction時，會對Requests進行retry，如果earlier transactions完成并釋放資源了，就可以發(fā)送PCrdGrant響應(yīng)允許二次發(fā)送命令。當Completer對request進行retry，它需要記錄該筆request的來源(通過SrcID)，也需要決定和記錄Protocol Credit的類型，因為后續(xù)PCrdGrand的P-Credit type要和RetryAck中的一致。當Completer有資源后，它必須發(fā)送通過PCrdGrant響應(yīng)發(fā)送P-Credit給Requester，通知Request被retry的transaction可以再發(fā)送；

由于ICN可能reorder PCrdGrant和RetryAck，會導致Request先收到PCrdGrant后收到RetryAck的情況，在這種場景下，Requester必須記錄已經(jīng)接收到的P-Credit，包括credit類型，這樣子收到RetryAck響應(yīng)時就可以正確的選擇P-Credit，不過這種場景很少見。

當Requester接收到一個P-Credit，重發(fā)request時不能將AllowRetry域置位，因此該request已經(jīng)保證可以被接收了。在transaction被重新發(fā)送的時，所有的域段都必須相同，除了以下幾個：

TgtID

Qos

TxnID

對于HN發(fā)往SN的ReadNoSnpSep和ReadNoSnp命令的ReturnTxnID

RSVDC

AllowRetry必須不置位

PCrdType必須設(shè)置為Retry response中的值；

TraceTag

P-Credit和transactions之間沒有固定的關(guān)系，如果Requester收到多筆RetryAck響應(yīng)，但只得到一個P-Credit，那么Requester可以自由選擇一個最適合的被retry的transaction來消耗這個P-Credit。Retry機制支持16種不同的P-Credit type，因此Completer可以用不同的P-Credit type來服務(wù)不同的資源。比如：Completer可能使用一種P-Credit type標識Read transactions的資源，用另一種P-Credit type標識Write transactions的資源。用不同的P-Credit type來控制被retried request的發(fā)送，使得Completer有效的管理它的資源。因為，Requester只有收到的PCrdGrant中的PCrdType和RetryAck中的PCrdType一致才能重新發(fā)送被retry的命令。

為了正確的分發(fā)P-Credit，Completer必須有能力記錄所有被Retry的命令。如果Completer使用多種P-Credit type給RetryAck響應(yīng)，那么每種P-Credit type都必須被記錄；Requester必須要限制發(fā)送的outstanding transactions的數(shù)目不要達到256，這樣Completer可以永遠不需要去跟蹤超過256的RetryAck命令。

一筆outstanding的transaction從該筆命令發(fā)送的當前時鐘周期開始，直到以下兩種情況：

該筆transaction完全結(jié)束，通過以下幾種響應(yīng)決定：ReadReceipt，CompData，DBIDResp，Comp，CompDBIDResp；

接收到RetryAck和PCrdGrant，并且如下選擇一種：a. 被Retry的命令重新發(fā)送并收到所有的響應(yīng)；b. 使用PCrdRetrun message將P-Credit返回回去，即取消重新發(fā)送；

Requester在以下情況可以選擇reuse TxnID：

一筆request被收到RetryAck響應(yīng)的TxnID；

對于non-retry request，收到該筆request的所有響應(yīng)；

每一筆transaction request包含一個Qos值，可以用于影響Completer在有資源時分配P-Credit。

1、Credit Return

Requester可能收到比需要更多的P-Credits，CHI協(xié)議沒有定義這種場景會發(fā)生，但有兩種典型的場景是：

在第一次發(fā)送到收到PCrdGrant之間就把transaction取消掉了；

一筆transaction要求隨著Qos值的增加多次傳輸，但是只有一筆完成響應(yīng)需要；

Requester通過PCrdRetrun返回P-Credit，告知Completer PCrdType分配的資源已經(jīng)不需要了，任何不需要的P-Credit都需要及時釋放掉，不能保留它們以備后續(xù)使用，這樣可能會造成資源浪費并且給分析系統(tǒng)性能帶來困難；

2、Transaction Retry mechanism

本小結(jié)闡述request transaction中用于Retry相關(guān)的域段，PrefetchTgt不支持retry。
AllowRetry：

AllowRetry指示一筆transaction能否被Retry。如果transaction是第一次發(fā)送，那么AllowRetry必須置位；AllowRetry在以下情況下必須不置位：

transaction使用pre-allocated P-Credit；

transaction是PrefetchTgt；

PCrdType：
PCrdType指示request請求中的credit type類型，具體取值按如下原則：

對于Request transaction：如果AllowRetry置位，那么PCrdType域值設(shè)置為0b000；如果AllowRetry不置位，那么PCrdType域值必須等于RetryAck響應(yīng)中的PCrdType的值；

PCrdRetrun transaction必須設(shè)置credit type等于Completer返回的credit type；

對于Completer只有一個簡單的credit分類，或沒有credit分類，CHI協(xié)議建議將PCrdType域值設(shè)置為0b000；

Completer在實現(xiàn)時必須考慮放餓死機制，確保所有的transactions不管它們的Qos值或需要credit type類型，即時需要很長時間，最終都可以進行執(zhí)行下去。這個可以通過給每個已經(jīng)收到RetryAck的transaction都確保分配credit來保證。
下圖展示了transaction retry flow的示意圖：

二、各請求命令傳輸結(jié)構(gòu)（Transaction Structure）

根據(jù)transactions的不同可以分類為：Read、Dataless、Write、Atomic、Other、Snoop。這些類型在《CHI基本概念介紹》中有講解，本節(jié)將按如下方式闡述Transaction structure：

Request transactions without a Retry，對于完整的Request transaction流程，Snoop transaction可能也需要，但是對于Requester來說不可見，因此本節(jié)將兩者分開描述；

Request transactions with a Retry，除了PCrdReturn和PrefetchTgt命令，其余命令都支持Retry操作，為了便于討論，Retry流程也將單獨討論；

Snoop transactions；

2.1Read Transactions

2.1.1Snoop Reads excluding ReadOnce*

除了ReadOnce*操作，snoopable讀操作有：

ReadClean

ReadNotSharedDirty

ReadShared

ReadUnique

snoopable讀操作通常是RN-F發(fā)出的，用于獲取其它RN或SN的數(shù)據(jù)，該數(shù)據(jù)會被cache所緩存。
根據(jù)數(shù)據(jù)來源的不同可以分為以下三類：

2.1.1.1Read transaction structure with DMT

DMT用于當數(shù)據(jù)可以直接從SN發(fā)送給原始Requester，傳輸結(jié)構(gòu)如圖1所示。對于Request/Response必須遵循的原則如下：

Completer必須收到讀請求后，才能發(fā)送相應(yīng)的CompData；

Requester必須收到至少一個CompData packet后，才能發(fā)送CompAck，在issueC之前，是必須全部收到數(shù)據(jù)包后，才能發(fā)送；

圖1 Snoopable Read DMT structure

DMT限制：

必須所有帶TxnID的Response都返回后，Requester才能重復(fù)利用該TxnID；

HN只有滿足以下條件才能發(fā)送DMT請求給SN-F：

1. Snoop請求不需要發(fā)送；

2. 如果snoop請求已經(jīng)發(fā)送了，所有的snoop響應(yīng)都已經(jīng)回來，且沒有Dirty數(shù)據(jù)；

3. 如果snoop響應(yīng)包含有Partial Dirty數(shù)據(jù)，Partial Dirty數(shù)據(jù)必須寫到SN-F，且收到completion響應(yīng)后，HN才能發(fā)送DMT請求；

4. 如果是Forwarding類型的snoop請求，只有沒有forward傳輸給Requester，HN才允許發(fā)送DMT請求；

注意：HN可以同時使能DMT和DCT，但是必須等DCT響應(yīng)回來后，才能發(fā)送DMT請求給SN-F。

2.1.1.2Read transaction structure with DCT

DCT用于被snoop的RN-F可以直接返回數(shù)據(jù)給原始Requester，傳輸結(jié)構(gòu)如圖2所示。對于Request/Response必須遵循如下原則：

Completer必須收到snoop請求后，才能發(fā)送CompData；

Requester必須收到至少一個CompData packet后，才能發(fā)送CompAck，在issueC之前，是必須收到全部數(shù)據(jù)包后，才能發(fā)送；

圖2 Snoopable Read DCT structure

2.1.1.3Read transaction structure without Direct Data Transfer

除了DMT和DCT，讀傳輸中，Requester所得到的數(shù)據(jù)可以由HN提供，傳輸結(jié)構(gòu)如圖3所示。同樣的，Requester必須收到至少一個CompData paCompAckcket后，才能發(fā)送。

圖3 Snoopable Read structure without Direct Data Transfer

2.1.2ReadNosnp，ReadOnce*

為什么將ReadNoSnp和ReadOnce放在一起說呢？我猜是因為它們兩者都有可選的保序需求和可選的CompAck；如果ReadNoSnp和ReadOnce要求具有保序功能，那么HN必須確保當前保序transaction對于后續(xù)的保序transactions是可見的；如果ReadNoSnp和ReadOnce將ExpCompAck置位，即使用CompAck，那么這它們將支持DMT和分離的Comp與Data響應(yīng)；

ReadNoSnp傳輸不會去snoop其它master，只是簡單的執(zhí)行讀傳輸流程，它所獲得的數(shù)據(jù)可以直接來自SN，也可以來自ICN；

ReadOnce傳輸需要去snoop其它master，但是Requester不會緩存該數(shù)據(jù)，同樣它所獲得的數(shù)據(jù)可以直接來自SN，也可以來自ICN；

2.1.2.1 ReadNoSnp and ReadOnce* structure with DMT

ReadNoSnp和ReadOnce使用DMT傳輸如圖4所示，如果Requester置起order域，那么HN必須通過CRSP通道返回ReadReceipt，表示保序已經(jīng)在HN上建立；如果HN往SN發(fā)送ReadNoSnp操作時置起order域，那么SN也需要返回ReadReceipt表示該筆transaction已經(jīng)接收，不會被Retry了。

圖4 ReadNoSnp and ReadOnce DMT structure

使用DMT的ReadNoSnp和ReadOnce命令在HN上的生命周期可以通過SN發(fā)送的ReadReceipt來縮短，即HN收到ReadReceipt后，就可以提前釋放這些命令的資源，不需要等到后續(xù)的CompAck。具體ReadNoSnp/ReadOnce與DMT、ReadReceipt、CompAck、order域段之間的關(guān)系在下面有專題論述。

2.1.2.2ReadOnce* structure with DCT

ReadNoSnp不需要snoop transaction，所以就沒有DCT說法了。對于ReadOnce的DCT傳輸如圖5所示，DCT傳輸需要被snoop的RN返回response表示當前DCT是否成功進行。

圖5 ReadOnce DCT structure

2.1.2.3ReadNoSnp and ReadOnce* structure without Direct Data transfer

ReaNoSnp和ReadOnce*沒有數(shù)據(jù)傳輸如圖6所示。Request/Response必須遵循如下原則：

ReadReceipt必須在相應(yīng)的請求接收后才能發(fā)送，返回ReadReceipt和CompData之間的順序無要求；

CompData必須在響應(yīng)的請求接收后才能發(fā)送；

CompAck必須在requester接收至少一個CompData packet之后才能發(fā)送，Requester發(fā)送CompAck可以不需要等待ReadReceipt，Completer發(fā)送ReadReceipt不能等待CompAck；

圖6 ReadNoSnp and ReadOnce* structure without Direct Data Transfer

下表2列出DMT和DCT與order域、CompAck不同組合后對ReadNoSnp和ReadOnce的影響。
表2 Permitted DMT and DCT for ReadNoSnp and ReadOnce from an RN

2.1.2.4Read with separate Non-data and Data-only responses

從issueC開始，對于所有的讀類型transaction，CHI支持分離的來自HN的non-data response和來自HN或SN的Data-only response；該特性在以下transactions不支持：

Atomic transactions

Exclusive transactions

Ordered ReadNoSnp and ReadOnce* transactions without CompAck

分離的Non-data和Data-only響應(yīng)有以下兩種方式：
1.comp來自HN，Data來自SN，如圖7所示：

圖7 Comp from Home and Data from Slave

2.comp和data都來自HN，如圖8所示：

圖8 Comp and Data from Home

注：對于非保序的帶CompAck的ReadOnce*和ReadNoSnp命令，requester發(fā)送CompAck不需要等待DataSepResp。
在分離comp和data響應(yīng)中，Request和Response需要遵循如下原則：

DataSepResp和RespSepData必須在completer接收到相應(yīng)的請求后才能發(fā)送，RespSepData只能由HN發(fā)送，DataSepResp可以由SN或HN發(fā)送；

在ReadNoSnp和ReadOnce*中，對于無保序的請求，CompAck可以不等待data返回就發(fā)送，對于有保序的請求，CompAck必須等待data返回后才發(fā)送；

Completer不能等待收到CompAck后才發(fā)送Data Packets；

ReadNoSnoSep必須在HN收到所有的Snoop響應(yīng)后，由HN發(fā)往SN；SN在收到ReadNoSnpSep后，必須返回Readreceipt，表明該筆transaction不會被retry；

SN不能呢發(fā)送分離的comp響應(yīng)給HN，對于保序的ReadOnce*和ReadNoSnp請求，HN通過收到CompAck可以知道該transaction已經(jīng)結(jié)束；

對于保序的ReadOnce和ReadNoSnp命令，如果采用分離的Comp和Data響應(yīng)，HN不能發(fā)送ReadReceipt響應(yīng)給requester，因為HN發(fā)送的RespSepData響應(yīng)已經(jīng)蘊含了ReadReceipt；

在所有可以使用分離回data和comp響應(yīng)的地方，也都可以使用CompData響應(yīng)；

對于ReadNoSnp和ReadOnce操作，不同的order值、ExpCompAck值，可以使用分離Non-data與Data-only響應(yīng)和CompData響應(yīng)的具體細則可以參考issueC文檔中表2-7，這里不細述。

2.2ataless Transactions

對于Dataless操作，主要用于以下功能：

獲取對cache的寫權(quán)限（CleanUnique/MakeUnique）；

cache維護（CMO：CleanShared/CleanSharedPersist/CleanInvalid/Makeinvalid）；

更新snoop fliter的狀態(tài)（Evict）；

將數(shù)據(jù)移到更接近的地方，方便可預(yù)見的將來使用（StashOnceUnique/StashOnceShared）；

對于Dataless傳輸?shù)牧鞒倘缦聢D所示9，從RN視角：

圖9 Snoopable Dataless transaction structure
對Request/Response的約束如下：

Completer必須在收到響應(yīng)的請求后，才能發(fā)送Comp；

Requester必須在收到響應(yīng)的Comp后，才能發(fā)送CompAck；

不是所有的Dataless操作都需要CompAck響應(yīng)，只有CleanUnique/MakeUnique才需要置起ExpCompAck，其余Dataless命令不需要置起ExpCompAck。這個問題得想想？？？

2.3Write Transactions

2.3.1WriteNoSnp*

當對某個地址進行寫操作，且不需要監(jiān)聽其它master是否有該地址的數(shù)據(jù)時，可以用WriteNoSnp命令;

對于WriteNoSnp命令，completer可以返回CompDBID，也可以將Comp和DBID分開返回；Comp表示該transaction可以被其它Requester觀察到，DBID表示該Completer有足夠data buffer接收寫數(shù)據(jù)；傳輸結(jié)構(gòu)如圖10所示。

圖10 WriteNoSnp* transaction structure options

對于Request/Response需要遵循的原則如下：

1.分離的DBID和Comp，或者CompDBID都必須在Completer收到相應(yīng)的請求后，才能由Completer發(fā)送；
2.Reuqester只有在收到CompDBID或DBIDResp后，才能發(fā)送寫數(shù)據(jù)；
3.如果Comp和DBID分開發(fā)送，Requester等到DBIDResp后，就需要發(fā)送寫數(shù)據(jù)，不能等到Comp之后才發(fā)送；DBIDResp和Comp對于Requester的接收和Completer的發(fā)送都是in any order；
4.Completer允許在收到WriteData后才發(fā)送Comp響應(yīng)；

2.3.2WriteUnique*

當對某個地址進行寫操作，且需要監(jiān)聽其它master時，可以使用WriteUnique命令；WriteUnique操作的傳輸結(jié)果如圖11所示，從RN視角。WriteUnique命令也可以使用分離的Comp和DBID響應(yīng)，或CompDBID響應(yīng)，作用和WriteNoSnp一樣；如果ExpCompAck域段置位，那么WriteUnique需要發(fā)送CompAck來結(jié)束命令，從issueC開始，有一個取巧方式是CompAck和Data可以組合為NCBWrDataCompAck一塊發(fā)送，省的發(fā)兩次。

圖11 WriteUnique transaction structure options

對于Request/Response的約束和2.3.1節(jié)基本一樣，不同點有兩個：

1. WriteUnique操作中，Completer不能等待WriteData后再發(fā)送Comp，我才猜想如果這樣做會有死鎖風險，比如說Data是以NCBWrDataCompAck的形式返回的話，Requester會等待Completer發(fā)送Comp，而Completer會等待Requester發(fā)送Data，造成互相等待死鎖；

2. Requester必須在收到Comp或CompDBIDResp后才能發(fā)送CompAck；

2.3.3CopyBack（WriteBack*/WriteCleanFull/WriteEvitFull）

除了WriteEvictFull命令，CopyBack操作通常用于更新主存或下游cache，WriteEvictFull單單用于更新下游cache，該命令產(chǎn)生的效果不會超過它的snoop domain；CopyBack操作流程如圖12所示。

CopyBack命令有兩個注意點：1. Comp和DBID必須一塊返回，即為CompDBIDResp；2. Requester收到CompDBIDResp后，表明Completer可以接收該命令的，而且在該命令結(jié)束前，不會接收到同地址的snoop命令。

圖12 CopyBack transaction structure

2.4Atomic Transactions

Atomic操作可以分為兩類：

一類是返回只有completion響應(yīng)，有：AtomicStore；

一類是返回有completion和Data響應(yīng)，有：AtomicLoad/AtomicSwap/AtomicCompare；

Atomic傳輸結(jié)果如圖13所示：

圖13 Atomic transaction structure

對于AtomicStore操作，允許Completer分開返回DBID和Comp響應(yīng)，或組合的CompDBID；對于AtomicLoad/AtomicSwap/AtomicCompare操作，Completer只能返回DBIDResp，Comp是通過CompData返回的；

在分離的Comp和DBIDResp中，Completer不能等待收到Data后才發(fā)送DBIDResp，但是允許等到Data之后再發(fā)送Comp，如果這樣做的話，就可以使用Comp來傳遞原子操作結(jié)果或數(shù)據(jù)接收是否有錯誤；

在CompDBID中，Completer不能等待收到Data之后才發(fā)送CompDBID響應(yīng)；Requester在收到DBIDResp活CompDBIDResp之后，就可以發(fā)送Data，不能等CompData或Comp響應(yīng)；

Completer在返回read data時可以采用兩種方式：1. 在收到命令之后的任何節(jié)點返回Read data；2. 直到收到所有的write data之后再返回read data；

Atomic操作的self-snoop：
在Atomic操作中，CHI協(xié)議允許Requester對自己進行self-snooping，如果SnoopMe域段置位，則允許self-snooping。通常RN在發(fā)送Atomic操作之前無法失效掉自己的cacheline的話，則需要self-snooping：1. 失效掉自己的cache line拷貝，2. 如果cache line時Dirty，則獲取一份拷貝；

HN收到SnoopMe置位的Atomic操作時，如果Requester里該cache line有數(shù)據(jù)，則必須發(fā)送snoop請求，反之可以不需要；如果SnoopMe為0，則不能發(fā)送snoop給Requester；HN發(fā)送給Requester的snoop命令可以是SnpUnique或SnpCleanInvalid；

注意：如果Atomic命令的SnoopMe置位，則RN可以發(fā)送同時并行發(fā)送同地址的CopyBack命令和Atomic操作，不需要等待同地址的其中某個操作完成后再發(fā)送下一個。

2.5Other Transactions

2.5.1DVM transaction

DVM是Distributed Virtual Memory的縮寫，DVM傳輸流程如圖14所示；Request/Response需要遵循如下原則：

Completer必須收到相應(yīng)的請求命令后才能發(fā)送DBIDResp；

Requester必須收到DBIDResp之后才能發(fā)送WriteData；

Completer必須收到Data后才能發(fā)送Comp響應(yīng)；

圖14 DVM transaction structure

2.5.2Prefetch transaction

PrefetchTgt是由RN直接發(fā)到SN，SN收到該命令可以采用兩種做法：1. 去主存取數(shù)據(jù)，并將數(shù)據(jù)緩存起來，等待接下來同地址的讀請求；2. 直接將命令丟棄掉，不做任何處理。傳輸流程如圖15所示：

圖15 PrefetchTgt transaction structure

對于Request/Response需要遵循如下原則：

Requester在發(fā)送完P(guān)refetchTgt命令后，馬上釋放資源；

SN不會講PrefetTgt命令retry；

SN可以將PrefetchTgt命令扔掉，不采取任何進一步措施；

2.6Transaction Retry sequence

除了PCrdReturn和PrefetchTgt命令，其它request命令都可以被retry。Request命令第一次發(fā)送時是不帶Protocol Credit（P-Credit），如果該命令不能被Completer接收，Completer必須發(fā)送RetryAck響應(yīng)表明暫時無法接收該命令，等到有合適的Credit后再發(fā)。當Completer可以接收的話，再發(fā)送PCrdGrant響應(yīng)給Requester。此時CHI協(xié)議允許被retry的命令是否要重發(fā)，因此有兩種情況需要討論。下面分別闡述：

2.6.1Retry sequence

如果需要重發(fā)的話，則必須攜帶PCrdGrant的Credit，確保命令肯定能被接收，傳輸結(jié)構(gòu)如圖16所示。

圖16 Transaction Retry sequence

對于retry的transaction有以下約束：

Completer必須收到相應(yīng)的請求命令后才能發(fā)送RetryAck；

Completer必須收到相應(yīng)的請求命令后才能發(fā)送PCrdGrant；

Completer發(fā)送和Requester接收的RetryAck和PCrdGrant之間的順序沒有要求；

Requester必須收到RetryAck和PCrdGrant之后，才能重新發(fā)送帶Credit的transaction；

2.6.2Not retrying a transaction

如果Requester在收到RetryAck和PCrdGrant后，并不想重新發(fā)送transaction，可以使用PCrdReturn命令將P-Credit返回給Completer，這樣相當于發(fā)了一筆空操作，傳輸結(jié)構(gòu)如圖17所示。

圖17 Cancelled transaction sequence

2.7Snoop Transactions

Snoop操作是由HN發(fā)給RN的transaction：

如果是RN-F需要接收所有的Snoop transaction；

如果是RN-D要只接收SnpDVMOp transaction；

RN-F和RN-D在收到snoop request（除了DVMOp Sync）時，必須要及時返回snoop響應(yīng)，不能和其它oustanding requests有任何的完成依賴關(guān)系。

snoop transaction的傳輸結(jié)構(gòu)有以下幾種：

Snoop with response to Home

Snoop with Data to Home

Snoop with Data return to Requester and response to Home

Snoop with Data return to Requester and Data to Home

Snoop DVM operation and response to Misc Node

snoop transaction也可以用于stash數(shù)據(jù)在Snoopee處，Stash類型的snoop transaction有以下幾種：

Stashing snoop with Data from Home

Stashing snoop with Data using DMT

2.7.1Snoop with response without Data to Home

該傳輸結(jié)構(gòu)如圖18所示，RN必須在收到相應(yīng)的Snoop請求后才能發(fā)送SnpResp響應(yīng)。

圖18 Snoop transaction structure with response to Home

2.7.2Snoop with response with Data to Home

該傳輸流程如圖19所示，只有如下幾種snoop請求才能有data響應(yīng)：

SnpOnceFwd，SnpOnce

SnpCleanFwd，SnpClean

SnpNotSharedDirty，SnpNotSharedDirty

SnpSharedFwd，SnpShared

SnpUniqueFwd，SnpUnique

SnpCleanShared

SnpCleanInvalid

RN可以通過SnpRespData和SnpRespDataPtl響應(yīng)返回數(shù)據(jù)，同樣的SnpRespData*只有在RN收到相應(yīng)的snoop請求后才能發(fā)送；

圖19 Snoop transaction structure with data to Home

2.7.3Snoop with Data forwarded to Requester without or with Data to Home

該傳輸流程如圖20和21所示，forward data的snoop請求有如下幾種：

SnpOnceFwd

SnpCleanFwd

SnpNotSharedDirtyFwd

SnpSharedFwd

SnpUniqueFwd

被Snoop的RN如果要forward數(shù)據(jù)給Requester，通過CompData opcode，走WDAT通道，因為forward是DCT傳輸，被snoop RN需要通知HN是否DCT成功，如果被snoop RN單單只回響應(yīng)，則通過SRSP通道和SnpRespFwded opcode告知HN，如果被snoop RN要把數(shù)據(jù)和響應(yīng)都要回，則通過WDAT通道和SnpRespDataFwded opcode告知HN。

圖20 Snoop with data forwarded to Requesterwith response to Home

圖21 Snoop with Data forwarded to Requester with Data to Home

對于forward snoop請求的request/response需要遵循如下規(guī)則：

被snoop RN只有在收到相應(yīng)的snoop請求后，才能發(fā)送SnpRespFwded或SnpRespDataFwded響應(yīng)，CompData同理；

被snoop的RN發(fā)SnpRespDataFwded或SnpRespFwded和CompData可以為任何順序；

Requester只有收到Data的第一筆數(shù)據(jù)后，才能發(fā)送CompAck；

2.7.4Snoop DVMOp

SnpDVMOp傳輸結(jié)構(gòu)如圖22所示，ICN需要發(fā)送兩個opcode為SnpDVMOp的snoop request，被snoop的RN需要接收到兩個snoop請求后，才能發(fā)送SnpResp響應(yīng)；

圖22 SnpDVMOp transaction structure

2.7.5Snoop DVMOp

Stash snoops傳輸?shù)慕Y(jié)構(gòu)情況較多，圖23和24分別給出了兩種情況：

圖23是帶Data Pull的響應(yīng)，因此HN需要發(fā)送Data給被snoop RN；
Data Pull指的是SnpResp響應(yīng)中蘊涵讀操作，即相當于既回了snoop響應(yīng)，也發(fā)了一筆讀操作；

圖23 Stash type snoop with Data Pull，Data response from Snoopee，and Data from Home

圖24也是帶Data Pull的響應(yīng)，但是被snoop RN回的響應(yīng)不帶數(shù)據(jù)，且HN采用DMT傳輸給被snoop RN提供數(shù)據(jù)；

圖24 Stash type snoop with Data Pull，no Data response from Snoopee，and DMT

三、傳輸響應(yīng)類型

除了PrefetchTgt，每一筆request transaction都會產(chǎn)生一個或多個響應(yīng)，有一些響應(yīng)可能還帶有數(shù)據(jù)，對于響應(yīng)類型可以按如：

3.1Completion response

除了PCrdRetrun和PrefetchTgt，其它request transaction都需要(completion response)完成響應(yīng)。完成響應(yīng)通常是由Completer發(fā)送的，是傳輸?shù)淖詈笠还Pmessage，用于結(jié)束一筆request transaction。然而，對于Requester可能仍然需要發(fā)送CompAck響應(yīng)來結(jié)束該筆transaction。完成響應(yīng)保證request transaction已經(jīng)到達PoS或PoC點，它們會對系統(tǒng)中其它requester發(fā)送的同地址requests進行保序。

3.1.1Read and Atomic transaction completion

Read transactions完成信號要么來自CompData，要不分離響應(yīng)RespSepData和DataSepResp。AtomicLoad、AtomicSwap、AtomicCompare的完成信號來自CompData。

CompData和DataSepResp完成信號的Resp域包含了如下信息：

Cache state：the final permitted state of the cache line at the Requester for all reads except ReadNoSnp and ReadOnce*.

Pass Dirty：Indicates if the responsibility for updating memory is passed to the Requester. The assertion of the PassDirty bit is shown by _PD in the response name.

當使用分離的Comp和Data響應(yīng)時，RespSepData響應(yīng)中也有包含帶有cache state和pass dirty的Resp域，RespSepData的Resp域要么不用設(shè)置為0，要么必須要和DataSepResp的Resp域一樣；

如果完成響應(yīng)含有error indication，那么cache state可以為任意值。

3.1.2Dataless transaction completion

Dataless transaction完成響應(yīng)是來自Comp，在Comp響應(yīng)的Resp域包含了如下信息：

Cache state：The final state the cache line is permitted to be in at the Requester，except for CMO transaction. For CMO transactions，the cache state field value is ignored and the cache state remains unchanged.

Pass Dirty：Dateless transactions do not pass responsibility for a Dirty cache line.

如果完成響應(yīng)含有error indication，那么cache state可以為任意值。

3.1.3Write and Atomic transaction completion

Write and AtomicStore完成響應(yīng)是來自Comp或CompDBID。對于write transaction沒有傳遞cache state和pass dirty信息，在Comp和CompDBIDResp響應(yīng)中的Resp域必須全部設(shè)置為0，所有的cache state和Pass dirty信息使用WriteData傳遞的。允許的Write transaction有：

Comp：用于分離的Comp和DBIDResp返回響應(yīng)；

CompDBIDResp：用于組合完成響應(yīng)，Non-CopyBack writes和AtomicStore可以分開Comp和DBIDResp響應(yīng)返回，也可以組合CompDBIDResp響應(yīng)返回。對于CopyBack writes只能組合CompDBIDResp響應(yīng)返回。

3.1.4Miscellaneous transaction completion

對于DVM transaction的完成響應(yīng)Comp的Resp域必須設(shè)置為0。

3.2WriteData response

WriteData response是Write request和DVMOp transactions的一部分。Requester在收到DBIDResp響應(yīng)后就可以將WriteData發(fā)往Completer。WriteData response是通過WDAT通道傳輸?shù)模幸韵聨追Nopcodes：

CopyBackWrData：1. 用于CopyBack transactions；2. 傳輸一致性數(shù)據(jù)從RN的cache到ICN；3. 包含WriteData響應(yīng)發(fā)送之前的cache line狀態(tài)信息。

NonCopyBackWrData：1. 用于WriteUnique和WriteNoSnp transactions；2. 用于DVMOp transaction；3. 響應(yīng)中的cache state必須是I態(tài)。

NCBWrDataCompAck：1. 用于WriteUnique transactions；2. 組合NonCopyBackWrData和CompAck；3. 響應(yīng)中的cache state必須是I態(tài)。

WriteData響應(yīng)中的Resp域包含如下信息：

Cache state：指示在WriteData響應(yīng)發(fā)送之前的cache line狀態(tài)信息。這個狀態(tài)信息不同于Requester最開始發(fā)送request時的cacheline狀態(tài)信息，因為在發(fā)送request和發(fā)送WriteData之間可能會收到同地址的snoop請求，snoop請求可能會將cache line狀態(tài)改變；

Pass Dirty：指示Requester是否將pass dirty傳遞給其它人，Pass Dirty bit置位的話在響應(yīng)名字上會帶有_PD；

在write transaction完成后，Requester的cache line狀態(tài)信息不是由WriteData響應(yīng)中cache state信息決定的，而是由transaction opcode決定transaction完成后cache line是否有效或無效：

WriteBack或WriteEvictFull transaction必須是I態(tài)；

WriteCleanFull transaction可以保持clean態(tài)；

如果WriteData的RespErr域指示有data error，WriteData響應(yīng)的cache line狀態(tài)可以為任意值。

Requester在發(fā)送WriteUniquePtl、WriteUniquePtlStash、WriteNoSnpPtl之后，Requester可以選擇取消transaction的進行，data響應(yīng)WriteDataCancel用于通知HN該筆寫已經(jīng)被取消了。

WriteDataCancel響應(yīng)規(guī)則如下：

只能用于WriteUniquePtl、WriteUniquePtlStash和WriteNoSnpPtl transaction；

不能用于Device memory type的WriteNoSnp transaction；

所有原先打算傳送的data packets必須發(fā)送；

WriteNoSnpPtl transaction不管是發(fā)送取消還是非取消的數(shù)據(jù)，都必須等到DBIDResp，不能等Comp；

WriteUniquePtl和WriteUniquePtlStash transactions不管是發(fā)送取消還是非取消的數(shù)據(jù)，都必須等到DBIDResp，不能等Comp；

對external interfaces可見的WriteDataCancel message必須將BE和Data域的值設(shè)置為0。External interfaces包括：1. External RN to ICN；2. ICN to an external SN。

3.3Snoop response

Snoop transaction包括snoop response，snoop response可以帶或不帶data。snoop response的Resp域包含如下信息：

Cache state：the final state of the cache line at the snooped node after sending the Snoop response.

Pass Dirty：Indicates that theresponsibility for updating memory is passed to the Requester or ICN. Pass Dirty must only be asserted for a Snoop response with data. The assertion of the Pass Dirty bit is shown by _PD in the response name.

snoop response也包含F(xiàn)wdState域的信息，該域用于DCT傳輸，用于指示DCT傳送給Requester的CompData中的cache state和pass dirty信息，即等于CompData的Resp域的值；

即時RespErr域指示有個錯誤，Snoop response with data上cache line state也必須是合法的值，但如果是snoop response without data就可以為任意值。

3.4Miscellaneous response

本節(jié)描述一些沒法歸類到Completion、WriteData、Snoop response的responses，本節(jié)的所有responses的Resp和RespErr域沒有任何意義且必須設(shè)置為0。包含這些response：

CompAck：1. Requester收到完成響應(yīng)之后就可以發(fā)送；2. 用于Read、Dataless、WriteUnique transactions；

RetryAck：1. 用于Completer在缺乏資源來接收request時，發(fā)送給Requester；2. 除了PCrdReturn和PrefetchTgt，其余request都可以被Retry；

PCrdGrant：傳遞P-Credit，Requester收到后可以發(fā)送被Retry的命令；

ReadReceipt：1. HN對要求Order的命令返回的保序保證；2. SN發(fā)送ReadReceipt表示它已經(jīng)接收read request，不會發(fā)送RetryAck響應(yīng)；3.只用于ReadNoSnp、ReadNoSnpSep、ReadOnce* request transactions；

DBIDResp：用于Write和Atomic transaction，告知Request在Completer有足夠的資源來接收WriteData響應(yīng)；

四、Cache state transitions

本節(jié)描述cache狀態(tài)悄悄轉(zhuǎn)換和各個request transaction的cache狀態(tài)切換和完成響應(yīng)(completion responses)

4.1Silence cache state transitions

由于內(nèi)部事件，cache可以悄悄轉(zhuǎn)換而不通知系統(tǒng)中的其它masters；表4為合法的silent cache state transaction。在一些情況下，RN可能但不是必須發(fā)送一筆transaction表明cache state轉(zhuǎn)換已經(jīng)發(fā)生。如果RN發(fā)送了這樣的一筆transaction，并且cache state轉(zhuǎn)換對ICN可見，那么這種情況就不能歸為silent transition。

對于表4中描述的RN-F local sharing是RN-F將Unique態(tài)改寫成Shared態(tài)，這種場景在一個RN-F內(nèi)有多個interna agents，cache line在它們之間變成shared時會發(fā)生。

對于silent cache state transaction：

Cache eviction和Local sharing transitions在任何point都可以發(fā)生，由具體實現(xiàn)決定；

Store和Cache Invalidate transitions只能是有意為之，在core執(zhí)行特定的程序指令時發(fā)生；

表4Legal silent cache state transitions，Notes那一欄表示如何在interface上將silent cache transitions轉(zhuǎn)換為non-silent orvisible轉(zhuǎn)換。

注意：
1、cache state不能從UC變?yōu)閁CE；
2、一系列silent transitions也可能發(fā)生，比如說從UC經(jīng)過Local Sharing變成UD，但又經(jīng)過cache Invalidate變成I態(tài)等一串silent操作。

4.2Read request transactions

不管原始request是什么，SN發(fā)往Requester的Data response的cache state通常是UC。對于ReadNoSnp、ReadOnce*的CompData Response，Requester必須忽略cache state，因為這些操作的cache state隱含為I態(tài)。

在non-DMT data transfer，SN發(fā)往HN的CompData的cache state可以是I或UC態(tài)，但是期望SN可簡化設(shè)計為總是使用UC，HN使用合適的cache state值CompData給Requester。

表5為在Requester上的讀請求的cache state transitions和completion response

注意：
1、表5中的Other Permitted initial cahce state是在transaction傳輸過程中允許的cache state；
2、表5中的任何transaction，如果cache line可以silently transition到any Expected或Other Permitted state，那也可以正常發(fā)送這些transaction，但這些silent transitions必須在transaction發(fā)送之前就應(yīng)該發(fā)生；
3、如果cache state為UD或SD，來自memory的data必須扔掉；如果是UDP，那必須merge；如果是SC或UC，來自memory的data必須和cached data一樣。

4.3Dataless request transactions

表6為在Requester的Dataless request所對應(yīng)的cache state transitions和completion responses。

注意：
1、在CleanInvalid、MakeInvalid、Evict transaction之前，允許cache state是UC、UCE或SC。但是在transaction要發(fā)送時，cache state必須轉(zhuǎn)換到I態(tài)，因此這三個命令的initial state只能是I態(tài)；
2、表6中的Other Permitted initial cahce state是在transaction傳輸過程中允許的cache state；
3、表6中的任何transaction，如果cache line可以silently transition到any Expected或Other Permitted state，那也可以正常發(fā)送這些transaction，但這些silent transitions必須在transaction發(fā)送之前就應(yīng)該發(fā)生。

4.4Write request transactions

表7為在Requester處Write和WriteBack request transactios所對應(yīng)的的cache state transitions、Write data response和組合或分離的Completion和DBID響應(yīng)。

注意：在WriteClean transaction完成后，Unique state的cache line可能會馬上轉(zhuǎn)變到Dirty state。

4.5Atomic transactions

表8為在Requester處的Atomic操作所對應(yīng)的cache state transitions和Completion response。

4.6Other request transactions

DVMOp和PrefetchTgt requests沒有任何的cache state transitions。

4.7Snoop request transactions

對于Non-forward snoop request，響應(yīng)只能是SnpResp或SnpRespData，在由多個可選的final cache state情況，response取決于具體實現(xiàn)；
RN處于UC態(tài)時，不需要返回snoop data response。除了SnpOnce，接收snoop response的Completer不能區(qū)分以下情況：

RN在UC態(tài)沒有返回帶data的snoop response；

在收到snoop request之前，RN silent transition到SC或I態(tài)，因此snoop response不帶data；

表9 Cache state，RetToSrc value，and valid completion responses

表10 Cache state transitions，RetToSrc value，and valid completion responses

表11Cache state transaction，RetToSrc value，and valid completion responses

表12Cache state transitions，RetToSrc value，and valid completion responses

4.8Stash type snoops

1、SnpUniqueStash and SnpMakeInvalidStash

SnpUniqueStash和SnpMakeInvalidStash的responses分別和SnpUnique和SnpMakeInvalid的responses一樣。對于SnpUniqueStash和SnpMakeInvalidStash的RetToSrc必須設(shè)置為0；如果DoNotDataPull沒有置位的話，snoop responses可以包含Data Pull。

表13Snoop response to SnpUniqueStash and SnpMakeInvalidStash

2、SnpStashUnique and SnpStashShared

Snoopee對于SnpStashUnique and SnpStashShared命令不會改變cache state。Snoopee允許不查找cache就返回response，在這種情況下snoop response必須是SnpResp_I。當然，Snoopee允許返回精確的cache state response；在response的cache state是精確的，且DoNotDataPull沒有置位的情況下，snoop response可以包含Data Pull；在包含Data Pull的Snoop response中，必須確保initial state不會和相應(yīng)的讀的initial state有沖突。

表14Snoop responses to SnpStashUnique

表15Snoop response to SnpStashShared

4.9Stash type snoops

Forwarding(Fwd) type snoop用于HN的DCT傳輸，對于所有在Snoopee的Fwd type snoops有如下規(guī)則：

如果是以下幾種cache state，那必須forward data給requester：UD、UC、SD、SC；

不允許轉(zhuǎn)化為相應(yīng)的Non-Fwd typesnoop；

對于Non-invalidation type snoop，Unique state不能forward data；

Snoopee收到DoNotGoTOSD置位的snoop請求，不能將cache state轉(zhuǎn)為SD，即時一致性條件允許；

在一定條件下，包括Snop type、the state of the cache line at the Snoopee，and the RetToSrc value in the Snoop request，Snoopee可以forward data給Request，也順帶發(fā)送一份數(shù)據(jù)給HN；

HN在以下情況不能發(fā)送forwarding type snoop：1. Atomic transactions；2. Passing Exclusive read transactions；

以下分別闡述每種特定的Fwd typ snoop：

1、SnpOnceFwd

除了以上common rules，Snoopee在收到SnpOnceFwd時，需要遵循如下規(guī)則：

Snoopee必須forward I態(tài)的cacheline，另外Snoopee不能Passdirty給Requester；

當Dirty state變?yōu)镃lean或Invalid，Snoopee必須返回數(shù)據(jù)給HN；

snoop的RetToSrc必須設(shè)置為0；

Snoopee可以忽略DoNotGoTOSD的值；

表16Snoop response to SnpOnceFwd

2、SnpCleanFwd

除了以上common rules，Snoopee在收到SnpCleanFwd時，需要遵循如下規(guī)則：

Snoopee必須forward SC態(tài)的cacheline；

Snoopee必須將cache state轉(zhuǎn)為SC、SD或I state；

表17Snoop response to SnpCleanFwd

3、SnpNotSharedDirtyFwd

除了以上common rules，Snoopee在收到SnpNotSharedDirtyFwd時，需要遵循如下規(guī)則：

Snoopee必須forward SC態(tài)的cacheline；

Snoopee必須將cache state轉(zhuǎn)為SC、SD或I state；

表18Snoop response to SnpNotSharedDirtyFwd

4、SnpSharedFwd

除了以上common rules，Snoopee在收到SnpSharedFwd時，需要遵循如下規(guī)則：

Snoopee必須forward SC態(tài)或SD態(tài)的cacheline；

Snoopee必須將cache state轉(zhuǎn)為SC、SD或I state；

表19Snoop response to SnpSharedFwd

5、SnpUniqueFwd

如果cache被緩存在唯一一個RN-F中，才能允許使用SnpUniqueFwd snoop；如果HN決定invalidating snoop需要被送到唯一cache上，HN可以發(fā)送SnpUniqueFwd給處于Shared態(tài)的RN-F；

除了以上common rules，Snoopee在收到SnpUniqueFwd時，需要遵循如下規(guī)則：

Snoopee必須forward Unique態(tài)的cacheline；

Requester上Dirty state的cacheline必須Pass dirty給Requester，而不是Home；

Snoopee必須將cache state轉(zhuǎn)為 I state；

Snoopee不能返回數(shù)據(jù)給HN；

snoop中的RetToSrc必須為0；

表20Snoop response to SnpUniqueFwd

6、SnpSharedFwd

除了以上common rules，Snoopee在收到SnpNotSharedDirtyFwd時，需要遵循如下規(guī)則：

Snoopee必須forward SC態(tài)的cacheline；

Snoopee必須將cache state轉(zhuǎn)為SC、SD或I state；

7、SnpSharedFwd

除了以上common rules，Snoopee在收到SnpNotSharedDirtyFwd時，需要遵循如下規(guī)則：

Snoopee必須forward SC態(tài)的cacheline；

Snoopee必須將cache state轉(zhuǎn)為SC、SD或I state；

4.10Shared clean state return

Snoop request中的RetToSrc域段用于指示Snoopee是否需要返回一份cacheline數(shù)據(jù)給HN，具體細則如下：

1、如果RetToSrc域值為1：

對于Forwarding snoop：如果cacheline是Dirty或Clean，Snoopee必須返回一份cacheline數(shù)據(jù)；

對于Non-forwarding snoops SnpOnce、SnpClean、SnpNotSharedDirty、SnpShared、SnpUnique：1. 對于SC態(tài)，必須返回一份數(shù)據(jù)給HN；2. 對于UD、UDP和SD態(tài)，必須發(fā)返回一份數(shù)據(jù)給HN；3. 對于UC態(tài)，可選是否返回一份數(shù)據(jù)給HN；

2、如果RetToSrc域值為0：

對于Forwarding snoop：1. 除了Snoopee的更新memory責任被pass給HN，或者Snoopee擁有UDP的cacheline且不愿意放棄這種狀態(tài)，其余情況都不能返回數(shù)據(jù)給HN；

對于Non-fowarding snoops SnpOnce、SnpClean、SnpNotSharedDirty、SnpShared、SnpUnique：1. 對于SC態(tài)，不能返回數(shù)據(jù)給HN；對于UD、UDP和SD態(tài)，必須返回數(shù)據(jù)給HN；3. 對于UC態(tài)，可選是否返回一份數(shù)據(jù)給HN；

在以下snoop requests，RetToSrc域值必須設(shè)置為0，因為這些snoops在clean態(tài)下不會返回數(shù)據(jù)：SnpStashUnique、SnpStashShared、SnpUniqueStash、SnpCleanShared、SnpCleanInvalid、SnpMakeInvalid、SnpMakeInvalidStash；
在嬰喜愛幾種Forwarding snoops中，RetToSrc域值必須設(shè)置為0：SnpOnceFwd、SnpUniqueFwd；
HN發(fā)送的Snoop requests中只能給一個RN設(shè)置RetToSrc為非0。

編輯：黃飛