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

一、傳輸通道和域段

1.1傳輸通道

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

表1

1.2域段

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

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)同一個(gè)transaction的所有packets；

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

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

Stash Node Identifier(StashNID)：該域段用于標(biāo)識(shí)Stash的目的節(jié)點(diǎn)；

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

Home Node Identifier：該域標(biāo)識(shí)了CompAck響應(yīng)應(yīng)該送到的節(jié)點(diǎn)；

在每個(gè)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時(shí)，記得遵循以下規(guī)定，就很easy了：

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

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

這里補(bǔ)充下LPID這個(gè)域段的一些知識(shí)：

CHI協(xié)議在Request transaction里定義了一個(gè)LPID，如果在一個(gè)Requester內(nèi)部包含多個(gè)logical processes，該域段用于標(biāo)識(shí)唯一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域也可以用于標(biāo)識(shí)發(fā)送transaction的original logical processor，但是該功能在CHI中是可選的。

1.2.2ID域段

Packet包含了其他的定義Transactions行為的屬性信息，這些屬性通過(guò)Packet域段傳遞到總線上，總線解析這些信息并采取相對(duì)應(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

對(duì)于REQ和SNP packet的地址域?yàn)椋?/p>

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

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

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

對(duì)于Read、PrefetchTgt、Datelss、Write、Atomic transactions，REQ的addr域就是要訪問(wèn)memory的地址信息；

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

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

PCrdRetrun transaction的地址域必須為0；

1.2.2.2Address

Request transaction可以定義Secure bit來(lái)指定該操作安全和非安全；對(duì)于Snoopable transactions，secure field可以認(rèn)為是附加的地址bit，因此相當(dāng)于定義了兩份地址空間：安全地址空間和非安全地址空間，硬件一致性沒(méi)法管理安全和非安全地址空間的一致性，因此使用時(shí)要正確處理好。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用于指示寫(xiě)完成信號(hào)從哪個(gè)節(jié)點(diǎn)返回。如果EWA置位，寫(xiě)完成信號(hào)可以來(lái)自中間節(jié)點(diǎn)(如：HN)，也可以來(lái)自endpoint(最終節(jié)點(diǎn))，來(lái)自中間節(jié)點(diǎn)的完成信號(hào)必須提供同樣的Comp響應(yīng)來(lái)保證；如果EWA不置位，寫(xiě)完成響應(yīng)必須來(lái)自最終節(jié)點(diǎn)；

注意：如果不實(shí)現(xiàn)EWA功能的話，那么寫(xiě)完成響應(yīng)必須來(lái)自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屬性指示訪問(wèn)的memory屬性是Device還是Normal。

Device memory type：

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

訪問(wèn)Device type memory空間的transaction有如下要求：

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

PrefetchTgt不能訪問(wèn)Device memory空間；

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

不能將多筆訪問(wèn)不同地址的請(qǐng)求組合成一筆，也不能將訪問(wèn)同一個(gè)地址的多個(gè)不同請(qǐng)求組合成一筆；

寫(xiě)操作不能merged；

訪問(wèn)Device memory的寫(xiě)操作的完成信號(hào)是來(lái)自中間節(jié)點(diǎn)的話，需要即使使寫(xiě)數(shù)據(jù)對(duì)endpoint節(jié)點(diǎn)可見(jiàn)。

訪問(wèn)Device memory的transaction必須使用以下類型：

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

必須使用WriteNoSnp或WriteNoSnpPtl去訪問(wèn)Device memory空間；

CMO和Atomic操作允許訪問(wèn)Device空間；

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

Normal memory type：

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

訪問(wèn)Normal memory空間在prefetching或forwarding上沒(méi)有和Device type memory空間同樣的約束：

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

寫(xiě)操作可以merged；

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

3、Cacheable

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

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

當(dāng)Cacheable沒(méi)置位時(shí)，transaction必須訪問(wèn)最終節(jié)點(diǎn)；

Cacheable attribute的值有如下要求：

對(duì)于任何的Device memory transaction，必須不置位；

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

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

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

在ReadNoSnpSep、ReadNoSnp、WriteNoSnpFull、WriteNoSnpPtl訪問(wèn)Normal memory空間時(shí)，可以為任何值；

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

在DVMOp和PCrdRetrun transaction中必須為0；

在PrefetchTgt中不會(huì)用，可以為任意值；

注意：如果一筆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中，但其實(shí)也可以分配的；
Allocate attribute值有如下要求：
可以在任意Cacheable置位的transaction中置位；
WriteEvictFull操作必須置位；如果WriteEvictFull的Allocate沒(méi)有置位，RN可以將其轉(zhuǎn)換為Evict操作；
對(duì)于Device memory transaction必須不能置位；
對(duì)于Normal Non-cacheable memory transaction中不能置位；
在DVMOp、PCrdRetrun和Evict操作中不使用，必須設(shè)置為0；
在PrefetchTgt中不使用，可以設(shè)置為任意值；

5、Propagation of Attr

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

當(dāng)知道downstream memory是Normal類型，那Device域值要設(shè)置為0來(lái)知識(shí)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域組合，并且等價(jià)于相應(yīng)的ARM memory type。表1 Legal combinations of MemAttr, SnpAttr, and Order field values

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

1、Device nRnE

Device nRnE memory type有如下行為：

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

2、Device nRE

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

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

3、Device RE

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

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

4、Normal Non-cacheable Non-bufferable

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

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

5、Normal Non-cacheable Bufferable

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

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

6、Write-back No-allocate

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

寫(xiě)響應(yīng)可以從中間節(jié)點(diǎn)返回；
寫(xiě)傳輸不要求對(duì)最終節(jié)點(diǎn)可見(jiàn)；
讀數(shù)據(jù)可以從中間cahce獲得；
讀操作可以prefetch預(yù)取；
寫(xiě)可以被merged；
讀和寫(xiě)transaction需要查找cache；
同一個(gè)源的讀和寫(xiě)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ù)，但其實(shí)也可以不緩存；

1.2.2.5Likely Shared

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

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

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域?yàn)楹沃担瑥腍N發(fā)送SN的CMO、ReadNoSnpSep和ReadNoSnp的SnpAttr域值必須設(shè)置為0。

注意：對(duì)于可以取多個(gè)SnpAttr值的transaction，SnpAttr通常是由page table(頁(yè)表) 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ù)場(chǎng)景使用：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沒(méi)有用到；

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

1.2.2.8Mismatched Memory attributes

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

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

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

1.2.2.9Data formatting

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

1、Data size

Size域段結(jié)合其它域段可以決定多少訪問(wèn)多少bytes，表3為不同Size域段對(duì)應(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，對(duì)于不同memory type，訪問(wèn)得到的byte數(shù)不一樣，具體如下：

2-a、Normal Memory

Normal memory type的transactions訪問(wèn)的byte數(shù)量取決于Size域，數(shù)據(jù)時(shí)從Aligned_Address(nearest Size boundary)到下一個(gè)Size boundary。計(jì)算方式為：
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訪問(wèn)的byte數(shù)量是從transaction address到next Size boundary，即the bytes accessed are from (Start_Address) to (Aligned_Address + Number_Bytes) - 1；
對(duì)于Device區(qū)間的寫(xiě)操作，Byte enables必須只對(duì)訪問(wèn)的bytes置位；

3、Byte Enables

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

對(duì)于Write transactions，BE置位意味著相應(yīng)data byte有效，且數(shù)據(jù)必須更新到memory或cache，BE不置位意味著相應(yīng)data byte無(wú)效，且數(shù)據(jù)不能更新到memory或cache。
在Write Data和Snoop response Data中，BE無(wú)效必須設(shè)置相應(yīng)byte value為0；
如果RN在發(fā)request和data之間，有snoop請(qǐng)求過(guò)來(lái)，將Dirty data snoop 走了，那么CopyBackWrData_I packet將會(huì)作為Data Response發(fā)送給HN，告知HN說(shuō)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ù)傳輸時(shí)必須將全部BE設(shè)置為1：

WriteNoSnpFull

CopyBack：WriteBackFull、WriteCleanFull、WriteEvictFull

WriteUniqueFull、WriteUniqueFullStash

對(duì)于以下Write transactions允許BE以任意組合，包括全部有效或全部無(wú)效：

WriteBackPtl

WriteUniquePtl、WriteUniquePtlStash

對(duì)于WriteNoSnpPtl transaction，有以下約束：

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

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

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

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

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

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

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

對(duì)于Snoop Responses with data使用SnpRespData opcode時(shí)，所有的BE都必須有效；

對(duì)于Snoop Responses with data使用SnpRespDataPtl opcode時(shí)，任意組合的BE都可以，包括全部有效或全部無(wú)效；

4、Critical chunk first wrap order

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

Number of bytes

Data bus width

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

Data bus width

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

128-bit

256-bit

512-bit

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

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

5、Data packetization

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

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

CCF_Wrap_Order at the ICN：True，ICN保證其有能力按接收順序保持一個(gè)transaction內(nèi)Data packets的順序；False，ICN不保證其有能力按接收順序保持一個(gè)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被接收，即要送來(lái)的數(shù)據(jù)就是critical chunk first wrap order；False，Receiver不要求data packets以critical chunk first wrap order被接收；

注意：在設(shè)計(jì)時(shí)，CCF_Wrap_Order參數(shù)可以幫助一個(gè)組件判斷是否需要以critical chunk first wrap order形式發(fā)送Data。例如：如果組件知道自己連接到out-of-order總線，那么它可以通過(guò)不支持以critical chunk first wrap order形式發(fā)送Data來(lái)簡(jiǎn)化它的data packet path。如果ICN支持CCF_Wrap_Order屬性，那么RN以critical chunk first wrap order發(fā)送data packets，receiver(SN)就可以以critical chunk first來(lái)接收數(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必須對(duì)應(yīng)于Start_Address所指定的data bytes；
b. 接下一筆必須對(duì)應(yīng)于地址遞增方向的data bytes，直到Upper_Wrap_Boundary；
c. 接下一筆必須對(duì)應(yīng)于Lower_Wrap_Boundary；
d. 接下一筆必須對(duì)應(yīng)于地址遞增方向的data bytes，直到Start_Address；

對(duì)于Data transfer examples可以參見(jiàn)CHI-issueC 122頁(yè)，這里不仔細(xì)說(shuō)明。

1.2.2.10Data formatting

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

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

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

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

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

TgtID

Qos

TxnID

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

RSVDC

AllowRetry必須不置位

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

TraceTag

P-Credit和transactions之間沒(méi)有固定的關(guān)系，如果Requester收到多筆RetryAck響應(yīng)，但只得到一個(gè)P-Credit，那么Requester可以自由選擇一個(gè)最適合的被retry的transaction來(lái)消耗這個(gè)P-Credit。Retry機(jī)制支持16種不同的P-Credit type，因此Completer可以用不同的P-Credit type來(lái)服務(wù)不同的資源。比如：Completer可能使用一種P-Credit type標(biāo)識(shí)Read transactions的資源，用另一種P-Credit type標(biāo)識(shí)Write transactions的資源。用不同的P-Credit type來(lái)控制被retried request的發(fā)送，使得Completer有效的管理它的資源。因?yàn)椋琑equester只有收到的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ù)目不要達(dá)到256，這樣Completer可以永遠(yuǎn)不需要去跟蹤超過(guò)256的RetryAck命令。

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

該筆transaction完全結(jié)束，通過(guò)以下幾種響應(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；

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

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

1、Credit Return

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

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

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

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

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請(qǐng)求中的credit type類型，具體取值按如下原則：

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

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

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

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

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

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

Request transactions without a Retry，對(duì)于完整的Request transaction流程，Snoop transaction可能也需要，但是對(duì)于Requester來(lái)說(shuō)不可見(jiàn)，因此本節(jié)將兩者分開(kāi)描述；

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

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ù)會(huì)被cache所緩存。
根據(jù)數(shù)據(jù)來(lái)源的不同可以分為以下三類：

2.1.1.1Read transaction structure with DMT

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

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

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

圖1 Snoopable Read DMT structure

DMT限制：

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

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

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

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

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

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

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

2.1.1.2Read transaction structure with DCT

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

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

Requester必須收到至少一個(gè)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必須收到至少一個(gè)CompData paCompAckcket后，才能發(fā)送。

圖3 Snoopable Read structure without Direct Data Transfer

2.1.2ReadNosnp，ReadOnce*

為什么將ReadNoSnp和ReadOnce放在一起說(shuō)呢？我猜是因?yàn)樗鼈儍烧叨加锌蛇x的保序需求和可選的CompAck；如果ReadNoSnp和ReadOnce要求具有保序功能，那么HN必須確保當(dāng)前保序transaction對(duì)于后續(xù)的保序transactions是可見(jiàn)的；如果ReadNoSnp和ReadOnce將ExpCompAck置位，即使用CompAck，那么這它們將支持DMT和分離的Comp與Data響應(yīng)；

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

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

2.1.2.1 ReadNoSnp and ReadOnce* structure with DMT

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

圖4 ReadNoSnp and ReadOnce DMT structure

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

2.1.2.2ReadOnce* structure with DCT

ReadNoSnp不需要snoop transaction，所以就沒(méi)有DCT說(shuō)法了。對(duì)于ReadOnce的DCT傳輸如圖5所示，DCT傳輸需要被snoop的RN返回response表示當(dāng)前DCT是否成功進(jìn)行。

圖5 ReadOnce DCT structure

2.1.2.3ReadNoSnp and ReadOnce* structure without Direct Data transfer

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

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

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

CompAck必須在requester接收至少一個(gè)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不同組合后對(duì)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開(kāi)始，對(duì)于所有的讀類型transaction，CHI支持分離的來(lái)自HN的non-data response和來(lái)自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來(lái)自HN，Data來(lái)自SN，如圖7所示：

圖7 Comp from Home and Data from Slave

2.comp和data都來(lái)自HN，如圖8所示：

圖8 Comp and Data from Home

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

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

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

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

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

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

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

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

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

2.2ataless Transactions

對(duì)于Dataless操作，主要用于以下功能：

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

cache維護(hù)（CMO：CleanShared/CleanSharedPersist/CleanInvalid/Makeinvalid）；

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

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

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

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

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

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

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

2.3Write Transactions

2.3.1WriteNoSnp*

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

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

圖10 WriteNoSnp* transaction structure options

對(duì)于Request/Response需要遵循的原則如下：

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

2.3.2WriteUnique*

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

圖11 WriteUnique transaction structure options

對(duì)于Request/Response的約束和2.3.1節(jié)基本一樣，不同點(diǎn)有兩個(gè)：

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

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

2.3.3CopyBack（WriteBack*/WriteCleanFull/WriteEvitFull）

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

CopyBack命令有兩個(gè)注意點(diǎn)：1. Comp和DBID必須一塊返回，即為CompDBIDResp；2. Requester收到CompDBIDResp后，表明Completer可以接收該命令的，而且在該命令結(jié)束前，不會(huì)接收到同地址的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

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

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

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

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

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

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

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

2.5Other Transactions

2.5.1DVM transaction

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

Completer必須收到相應(yīng)的請(qǐ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ù)緩存起來(lái)，等待接下來(lái)同地址的讀請(qǐng)求；2. 直接將命令丟棄掉，不做任何處理。傳輸流程如圖15所示：

圖15 PrefetchTgt transaction structure

對(duì)于Request/Response需要遵循如下原則：

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

SN不會(huì)講PrefetTgt命令retry；

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

2.6Transaction Retry sequence

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

2.6.1Retry sequence

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

圖16 Transaction Retry sequence

對(duì)于retry的transaction有以下約束：

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

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

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

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

2.6.2Not retrying a transaction

如果Requester在收到RetryAck和PCrdGrant后，并不想重新發(fā)送transaction，可以使用PCrdReturn命令將P-Credit返回給Completer，這樣相當(dāng)于發(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）時(shí)，必須要及時(shí)返回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請(qǐng)求后才能發(fā)送SnpResp響應(yīng)。

圖18 Snoop transaction structure with response to Home

2.7.2Snoop with response with Data to Home

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

SnpOnceFwd，SnpOnce

SnpCleanFwd，SnpClean

SnpNotSharedDirty，SnpNotSharedDirty

SnpSharedFwd，SnpShared

SnpUniqueFwd，SnpUnique

SnpCleanShared

SnpCleanInvalid

RN可以通過(guò)SnpRespData和SnpRespDataPtl響應(yīng)返回?cái)?shù)據(jù)，同樣的SnpRespData*只有在RN收到相應(yīng)的snoop請(qǐng)求后才能發(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請(qǐng)求有如下幾種：

SnpOnceFwd

SnpCleanFwd

SnpNotSharedDirtyFwd

SnpSharedFwd

SnpUniqueFwd

被Snoop的RN如果要forward數(shù)據(jù)給Requester，通過(guò)CompData opcode，走WDAT通道，因?yàn)閒orward是DCT傳輸，被snoop RN需要通知HN是否DCT成功，如果被snoop RN單單只回響應(yīng)，則通過(guò)SRSP通道和SnpRespFwded opcode告知HN，如果被snoop RN要把數(shù)據(jù)和響應(yīng)都要回，則通過(guò)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

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

被snoop RN只有在收到相應(yīng)的snoop請(qǐng)求后，才能發(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ā)送兩個(gè)opcode為SnpDVMOp的snoop request，被snoop的RN需要接收到兩個(gè)snoop請(qǐng)求后，才能發(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)中蘊(yùn)涵讀操作，即相當(dā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都會(huì)產(chǎn)生一個(gè)或多個(gè)響應(yīng)，有一些響應(yīng)可能還帶有數(shù)據(jù)，對(duì)于響應(yīng)類型可以按如：

3.1Completion response

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

3.1.1Read and Atomic transaction completion

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

CompData和DataSepResp完成信號(hào)的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.

當(dāng)使用分離的Comp和Data響應(yīng)時(shí)，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)是來(lái)自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)是來(lái)自Comp或CompDBID。對(duì)于write transaction沒(méi)有傳遞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可以分開(kāi)Comp和DBIDResp響應(yīng)返回，也可以組合CompDBIDResp響應(yīng)返回。對(duì)于CopyBack writes只能組合CompDBIDResp響應(yīng)返回。

3.1.4Miscellaneous transaction completion

對(duì)于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是通過(guò)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)信息。這個(gè)狀態(tài)信息不同于Requester最開(kāi)始發(fā)送request時(shí)的cacheline狀態(tài)信息，因?yàn)樵诎l(fā)送request和發(fā)送WriteData之間可能會(huì)收到同地址的snoop請(qǐng)求，snoop請(qǐng)求可能會(huì)將cache line狀態(tài)改變；

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

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

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的進(jìn)行，data響應(yīng)WriteDataCancel用于通知HN該筆寫(xiě)已經(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；

對(duì)external interfaces可見(jiàn)的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域的值；

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

3.4Miscellaneous response

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

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

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

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

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

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

四、Cache state transitions

本節(jié)描述cache狀態(tài)悄悄轉(zhuǎn)換和各個(gè)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)換對(duì)ICN可見(jiàn)，那么這種情況就不能歸為silent transition。

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

對(duì)于silent cache state transaction：

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

Store和Cache Invalidate transitions只能是有意為之，在core執(zhí)行特定的程序指令時(shí)發(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ā)生，比如說(shuō)從UC經(jīng)過(guò)Local Sharing變成UD，但又經(jīng)過(guò)cache Invalidate變成I態(tài)等一串silent操作。

4.2Read request transactions

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

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

表5為在Requester上的讀請(qǐng)求的cache state transitions和completion response

注意：
1、表5中的Other Permitted initial cahce state是在transaction傳輸過(guò)程中允許的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，來(lái)自memory的data必須扔掉；如果是UDP，那必須merge；如果是SC或UC，來(lái)自memory的data必須和cached data一樣。

4.3Dataless request transactions

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

注意：
1、在CleanInvalid、MakeInvalid、Evict transaction之前，允許cache state是UC、UCE或SC。但是在transaction要發(fā)送時(shí)，cache state必須轉(zhuǎn)換到I態(tài)，因此這三個(gè)命令的initial state只能是I態(tài)；
2、表6中的Other Permitted initial cahce state是在transaction傳輸過(guò)程中允許的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所對(duì)應(yīng)的的cache state transitions、Write data response和組合或分離的Completion和DBID響應(yīng)。

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

4.5Atomic transactions

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

4.6Other request transactions

DVMOp和PrefetchTgt requests沒(méi)有任何的cache state transitions。

4.7Snoop request transactions

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

RN在UC態(tài)沒(mé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一樣。對(duì)于SnpUniqueStash和SnpMakeInvalidStash的RetToSrc必須設(shè)置為0；如果DoNotDataPull沒(méi)有置位的話，snoop responses可以包含Data Pull。

表13Snoop response to SnpUniqueStash and SnpMakeInvalidStash

2、SnpStashUnique and SnpStashShared

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

表14Snoop responses to SnpStashUnique

表15Snoop response to SnpStashShared

4.9Stash type snoops

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

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

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

對(duì)于Non-invalidation type snoop，Unique state不能forward data；

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

在一定條件下，包括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時(shí)，需要遵循如下規(guī)則：

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

當(dāng)Dirty state變?yōu)镃lean或Invalid，Snoopee必須返回?cái)?shù)據(jù)給HN；

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

Snoopee可以忽略DoNotGoTOSD的值；

表16Snoop response to SnpOnceFwd

2、SnpCleanFwd

除了以上common rules，Snoopee在收到SnpCleanFwd時(shí)，需要遵循如下規(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時(shí)，需要遵循如下規(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時(shí)，需要遵循如下規(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被緩存在唯一一個(gè)RN-F中，才能允許使用SnpUniqueFwd snoop；如果HN決定invalidating snoop需要被送到唯一cache上，HN可以發(fā)送SnpUniqueFwd給處于Shared態(tài)的RN-F；

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

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

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

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

Snoopee不能返回?cái)?shù)據(jù)給HN；

snoop中的RetToSrc必須為0；

表20Snoop response to SnpUniqueFwd

6、SnpSharedFwd

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

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

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

7、SnpSharedFwd

除了以上common rules，Snoopee在收到SnpNotSharedDirtyFwd時(shí)，需要遵循如下規(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，具體細(xì)則如下：

1、如果RetToSrc域值為1：

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

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

2、如果RetToSrc域值為0：

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

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

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

編輯：黃飛