一文詳解CXL.cache協(xié)議

3.2 CXL.cache

3.2.1 概覽

CXL.cache協(xié)議將設(shè)備和主機(jī)之間的交互定義為多個(gè)請(qǐng)求，每個(gè)請(qǐng)求至少有一條相關(guān)的響應(yīng)消息，有時(shí)還有數(shù)據(jù)傳輸。該接口在每個(gè)方向上由三個(gè)通道組成：請(qǐng)求（Request）、響應(yīng)（Response）和數(shù)據(jù)（Data）。通道按其方向命名，D2H表示設(shè)備到主機(jī)，H2D表示主機(jī)到設(shè)備。

D2H請(qǐng)求通道，將新請(qǐng)求從設(shè)備傳送到主機(jī)。請(qǐng)求通常以內(nèi)存為目標(biāo)。每個(gè)請(qǐng)求將收到0、1或2個(gè)響應(yīng)，和最多一個(gè)64字節(jié)的緩存行。通道可以反壓（Back Pressure）。

D2H響應(yīng)通道，將設(shè)備的所有響應(yīng)傳送到主機(jī)。設(shè)備對(duì)監(jiān)聽(tīng)的響應(yīng)返回該緩存行在設(shè)備緩存中的狀態(tài)，并可能表示數(shù)據(jù)正返回到主機(jī)提供的數(shù)據(jù)緩沖區(qū)。對(duì)于鏈路層信用，它們可能仍會(huì)被暫時(shí)阻止，但不應(yīng)要求完成任何其他交易來(lái)釋放信用。

D2H數(shù)據(jù)通道，將所有數(shù)據(jù)和字節(jié)啟用從設(shè)備傳輸?shù)街鳈C(jī)。數(shù)據(jù)傳輸可以是隱式（由于監(jiān)聽(tīng)）或顯式寫(xiě)回（由于緩存容量而導(dǎo)致的“逐出”）的結(jié)果。在所有情況下，都將傳輸完整的64字節(jié)緩存行。D2H數(shù)據(jù)傳輸必須進(jìn)行，否則可能會(huì)出現(xiàn)死鎖。它們可能會(huì)因鏈路層信用暫時(shí)被阻止，但不得要求完成任何其他交易來(lái)釋放信用。

H2D請(qǐng)求通道，將請(qǐng)求從主機(jī)傳送到設(shè)備。這些請(qǐng)求都是為保持一致性的監(jiān)聽(tīng)。可能會(huì)返回?cái)?shù)據(jù)，請(qǐng)求攜帶數(shù)據(jù)緩沖區(qū)的位置，任何返回?cái)?shù)據(jù)都應(yīng)寫(xiě)入該緩沖區(qū)。

H2D響應(yīng)通道，攜帶排序消息并提取寫(xiě)入數(shù)據(jù)。每個(gè)響應(yīng)都攜帶來(lái)自原始設(shè)備請(qǐng)求的請(qǐng)求標(biāo)識(shí)符，以指示響應(yīng)應(yīng)該路由到哪里。

H2D數(shù)據(jù)通道，為設(shè)備讀取請(qǐng)求提供數(shù)據(jù)。在所有情況下，都將傳輸完整的64字節(jié)緩存行。

3.2.2 CXL.cache通道描述

通常，所有CXL.cache通道都必須彼此獨(dú)立工作。然而，有一個(gè)特例，為了保證正確性，必須維護(hù)通道之間的順序。主機(jī)需要等待設(shè)備觀察到H2D響應(yīng)上發(fā)送的全局排序（GlobalOrdering，GO）消息，然后再發(fā)送相同地址的后續(xù)監(jiān)聽(tīng)。為了限制跟蹤GO消息所需的緩沖量，主機(jī)保證通過(guò)CXL.cache發(fā)送的GO消息后，在一定周期內(nèi)不能再發(fā)送的監(jiān)聽(tīng)。

每個(gè)通道都必須使用信用來(lái)發(fā)送任何消息，并從接收方收集信用返回。在操作過(guò)程中，每當(dāng)接收器處理完消息后，它都會(huì)返回一個(gè)信用。如果沒(méi)有可用的信用，發(fā)送方必須等待接收方返回信用。下表描述了哪些通道必須被排空才能繼續(xù)，哪些通道可以無(wú)限期阻塞。

3.2.3 CXL.cache寫(xiě)描述

CXL.cache每個(gè)通道消息的字段定義如下。

3.2.3.1 D2H請(qǐng)求

關(guān)于Opcode，后面的章節(jié)會(huì)詳細(xì)描述這些D2H請(qǐng)求。

3.2.3.2 D2H響應(yīng)

3.2.3.3 D2H數(shù)據(jù)

3.2.3.4 H2D請(qǐng)求

3.2.3.5 H2D響應(yīng)

3.2.3.6 H2D數(shù)據(jù)

3.2.4 CXL.cache事務(wù)描述

3.2.4.1 D2H請(qǐng)求

D2H請(qǐng)求，有四種語(yǔ)義：CXL.cacheRead，CXL.cache Read0，CXL.cacheRead0/Write，CXL.cache Write。

CXL.cache Read

CXL.cache Read需要D2H請(qǐng)求信用，在D2H CXL.cache請(qǐng)求通道上發(fā)送請(qǐng)求消息。CXL.cache Read請(qǐng)求需要0或1條響應(yīng)（GO）消息和64字節(jié)緩存行的數(shù)據(jù)信息。響應(yīng)（如果存在）和數(shù)據(jù)消息都指向初始D2H請(qǐng)求分組的CQID字段中提供的設(shè)備跟蹤器條目。在收到來(lái)自主機(jī)的所有消息之前，設(shè)備條目必須保持活動(dòng)狀態(tài)。為確保向前進(jìn)度，設(shè)備必須具有保留的數(shù)據(jù)緩沖區(qū)，以便在發(fā)送請(qǐng)求后能夠立即接受所有64字節(jié)的數(shù)據(jù)。但是，由于先前的數(shù)據(jù)返回沒(méi)有排出，設(shè)備可能暫時(shí)無(wú)法接受來(lái)自主機(jī)的數(shù)據(jù)。一旦從主機(jī)接收到響應(yīng)消息和數(shù)據(jù)消息，就可以認(rèn)為事務(wù)已完成，并且條目已從設(shè)備中解除分配。

下圖顯示了CXL.cache Read的過(guò)程。需注意，響應(yīng)（GO）消息可以在數(shù)據(jù)消息之前、之后或之間接收。

CXL.cache Read0

CXL.cache Read0接受響應(yīng)消息，但是沒(méi)有數(shù)據(jù)消息。響應(yīng)消息指向初始D2H請(qǐng)求消息的CQID值中指示的設(shè)備條目。一旦收到這些請(qǐng)求的GO消息，就可以認(rèn)為它們已完成，并且條目已從設(shè)備中解除分配。主機(jī)不得為這些事務(wù)發(fā)送數(shù)據(jù)消息。

CXL.cache Write

CXL.cache Write需要D2H請(qǐng)求信用。主機(jī)收到請(qǐng)求消息后，需要發(fā)送兩條單獨(dú)的或一條合并的GO-I和WritePull消息。GO消息絕不能在WritePull之前到達(dá)設(shè)備，但它可以在組合消息中到達(dá)。如果事務(wù)是posted類型的寫(xiě)，那么合并的回復(fù)消息類型更能派上用場(chǎng)。如果是non-posted類型的寫(xiě)，host需要先發(fā)GO-I消息，再發(fā)WritePull消息。

下圖顯示了完成CXL.cache Write事務(wù)的過(guò)程，WritePull消息觸發(fā)數(shù)據(jù)消息。

下圖顯示了WritePull是來(lái)自GO的單獨(dú)消息的情況（強(qiáng)序不可緩存寫(xiě)請(qǐng)求）。

下圖顯示了主機(jī)FastGO和ExtCmp的響應(yīng)（弱序?qū)懻?qǐng)求）。

至于什么是強(qiáng)序，弱序，就不解釋了。

CXL.cache Read0-Write

CXL.cache Read0-Write需要D2H請(qǐng)求信用。WritePull消息會(huì)觸發(fā)設(shè)備發(fā)出64-byte數(shù)據(jù)給主機(jī)。一旦設(shè)備接收到GO-I消息并發(fā)送了所有所需的數(shù)據(jù)消息，則認(rèn)為CXL.cache Read0-Wrtie事務(wù)已完成。此時(shí)，可以從設(shè)備中釋放條目。主機(jī)在接收到所有64字節(jié)的數(shù)據(jù)并發(fā)送GO-I響應(yīng)消息后，會(huì)認(rèn)為Read0-Write結(jié)束。

D2H請(qǐng)求的opcode如下：

RdCurr：這些是來(lái)自設(shè)備的完整緩存行讀取請(qǐng)求，以獲取最新數(shù)據(jù)，但不會(huì)更改任何緩存（包括主機(jī)）中的現(xiàn)有狀態(tài)。主機(jī)不需要跟蹤發(fā)出RdCurr的設(shè)備中的緩存行。RdCurr獲取數(shù)據(jù)，但無(wú)法占有。設(shè)備接收到處于無(wú)效狀態(tài)的行，這意味著它只能使用一次該行，無(wú)法緩存該行。

RdOwn：來(lái)自設(shè)備的完整緩存行讀取請(qǐng)求，用于緩存處于任何可寫(xiě)（writable）狀態(tài)的行。通常，RdOwn請(qǐng)求接收處于Exclusive（GO-E）或Modified（GO-M）狀態(tài)的行。處于Modified狀態(tài)的緩存行，必須將其寫(xiě)回主機(jī)。在錯(cuò)誤情況下，RdOwn請(qǐng)求可能會(huì)收到處于Invalid（GO-I）或Error（GO-Err）狀態(tài)的行。兩者都將返回全是1的數(shù)據(jù)。設(shè)備負(fù)責(zé)處理錯(cuò)誤。

RdShared：設(shè)備發(fā)起讀取完整緩存行的請(qǐng)求，用于緩存處于Shared狀態(tài)的行。通常，RdShared請(qǐng)求接收處于共享（GO-S）狀態(tài)的行。在錯(cuò)誤情況下，RdShared請(qǐng)求可能會(huì)收到處于Invalid（GO-I）或Error（GO-Err）狀態(tài)的行。兩者都將返回全是1的數(shù)據(jù)。設(shè)備負(fù)責(zé)處理錯(cuò)誤。

RdAny：備發(fā)起讀、讀取完整緩存行的請(qǐng)求，用于緩存處于任何狀態(tài)的行。在錯(cuò)誤情況下，RdAny請(qǐng)求可能會(huì)收到處于Invalid（GO-I）或Error（GO-Err）狀態(tài)的行。兩者都將返回全是1的數(shù)據(jù)。設(shè)備負(fù)責(zé)處理錯(cuò)誤。

RdOwnNoData：設(shè)備向指定的緩存行地址發(fā)起該請(qǐng)求，目的是擁有獨(dú)占的權(quán)限。在錯(cuò)誤情況下，RdOwnNoData請(qǐng)求可能會(huì)收到處于Error（GO-Err）狀態(tài)的行。設(shè)備負(fù)責(zé)處理錯(cuò)誤。

ItoMWr：設(shè)備對(duì)指定的緩存行地址發(fā)起獨(dú)占權(quán)限請(qǐng)求，并以原子方式將緩存行寫(xiě)回主機(jī)。由于設(shè)備會(huì)將整個(gè)緩存行的數(shù)據(jù)都修改掉，所以不需要主機(jī)將該緩存行數(shù)據(jù)發(fā)給設(shè)備。當(dāng)主機(jī)給了請(qǐng)求該緩存行的獨(dú)占權(quán)限后，設(shè)備會(huì)回復(fù)響應(yīng)消息GO-I-WritePull。設(shè)備不需要再保留寫(xiě)回的數(shù)據(jù)。如果錯(cuò)誤發(fā)生，設(shè)備回復(fù)GO-Err-WritePull，主機(jī)丟棄設(shè)備寫(xiě)回的數(shù)據(jù)。設(shè)備處理該錯(cuò)誤。

MemWr：與ItoMWr有些類似，但是寫(xiě)回?cái)?shù)據(jù)的位置可能不同。只有當(dāng)命令命中緩存時(shí)，數(shù)據(jù)才會(huì)寫(xiě)入其中；如果未命中，數(shù)據(jù)將直接寫(xiě)入內(nèi)存。一旦請(qǐng)求被授予所有權(quán)，典型的響應(yīng)就是GO-I-WritePull。設(shè)備不保留該行的副本。如果錯(cuò)誤發(fā)生，設(shè)備回復(fù)GO-Err-WritePull，主機(jī)丟棄設(shè)備寫(xiě)回的數(shù)據(jù)。設(shè)備處理該錯(cuò)誤。

ClFlush：設(shè)備發(fā)起請(qǐng)求，無(wú)效掉指定地址的緩存行。主機(jī)返回的典型響應(yīng)是GO-I。

CleanEvict：設(shè)備發(fā)送請(qǐng)求給主機(jī)，要求evict一條64-byte的Exclusive緩存行。該請(qǐng)求會(huì)收到GO-WritePull或GO-WritePullDrop類型的響應(yīng)消息。不論設(shè)備收到哪種響應(yīng)消息，都必須放棄對(duì)該緩存行的監(jiān)聽(tīng)所有權(quán)限。如果收到的是GO-WritePull，那么設(shè)備將數(shù)據(jù)發(fā)送給主機(jī)，如果是GO-WritePullDrop，那么主機(jī)直接將該組數(shù)據(jù)丟棄。

DirtyEvict：設(shè)備發(fā)送請(qǐng)求給主機(jī)，要求evict一條64-byte的Modified緩存行。請(qǐng)求發(fā)出后，應(yīng)該收到的響應(yīng)消息是GO-WritePull，這也意味著device對(duì)該緩存行失去了監(jiān)聽(tīng)所有權(quán)，并需要將數(shù)據(jù)發(fā)送出去。一旦設(shè)備發(fā)起了這樣的一個(gè)請(qǐng)求，并且在設(shè)備接收到GO-WritePul或GO-WritePullDrop響應(yīng)消息前，訪問(wèn)的緩存地址已經(jīng)被監(jiān)聽(tīng)了，這時(shí)候，設(shè)備需要設(shè)置數(shù)據(jù)消息的Bogus字段，用來(lái)指示這個(gè)數(shù)據(jù)也許不是最新的。當(dāng)有錯(cuò)誤出現(xiàn)，主機(jī)回復(fù)GO-Err-WritePull，這個(gè)時(shí)候設(shè)備寫(xiě)回的數(shù)據(jù)會(huì)被主機(jī)丟棄掉。設(shè)備負(fù)責(zé)處理錯(cuò)誤。

CleanEvictNoData：設(shè)備發(fā)起請(qǐng)求給主機(jī)，以便在設(shè)備中刪除一條干凈的緩存行。此請(qǐng)求的唯一目的是更新主機(jī)中的監(jiān)聽(tīng)過(guò)濾器（snoop filter），并且不會(huì)交換任何數(shù)據(jù)。只有在主機(jī)掛載內(nèi)存的地址范圍內(nèi)，才需要CleanRecictNodeData。對(duì)于設(shè)備掛載內(nèi)存的地址范圍，等效操作可以在設(shè)備內(nèi)部完成，而無(wú)需向主機(jī)發(fā)送事務(wù)。

WOWrInv：弱順序?qū)憻o(wú)效緩存行（0-63byte）請(qǐng)求，可以設(shè)置字節(jié)啟用組合。通常，WOWrInv接收一個(gè)FastGO-WritePull，后跟一個(gè)ExtCmp。收到FastGO-WritePull后，設(shè)備會(huì)將數(shù)據(jù)發(fā)送到主機(jī)。對(duì)于主機(jī)掛載內(nèi)存，一旦內(nèi)存中的寫(xiě)入完成，主機(jī)就會(huì)發(fā)送ExtCmp。在錯(cuò)誤情況下，將收到GO-Err-Writepull。設(shè)備將正常發(fā)送數(shù)據(jù)，但主機(jī)將丟棄數(shù)據(jù)。設(shè)備負(fù)責(zé)處理錯(cuò)誤。在所有情況下，在GO錯(cuò)誤之后，主機(jī)仍將發(fā)送ExtCmp。

WOWrInvF：與WOWrInv類似，不同的是它是一條完整的緩存行（64byte），沒(méi)有字節(jié)使能。

WrInv：這是一個(gè)0-64字節(jié)的寫(xiě)無(wú)效行請(qǐng)求。通常，WrInv會(huì)收到一個(gè)WritePull，然后是GO。獲得WritePull后，設(shè)備將數(shù)據(jù)發(fā)送到主機(jī)。一旦內(nèi)存中的寫(xiě)入完成（主機(jī)掛載內(nèi)存或設(shè)備掛載內(nèi)存），主機(jī)將發(fā)送GO。在錯(cuò)誤情況下，會(huì)收到GO-Err。設(shè)備負(fù)責(zé)處理錯(cuò)誤。

CacheFlushed：設(shè)備通過(guò)此請(qǐng)求通知主機(jī)其緩存已刷新，并且不再包含處于Shared、Exclusive或Modified狀態(tài)的任何緩存行。主機(jī)可以使用此信息清除其監(jiān)聽(tīng)過(guò)濾器，阻止對(duì)設(shè)備的監(jiān)聽(tīng)并返回GO。一旦設(shè)備接收到GO，在設(shè)備發(fā)送下一個(gè)可緩存D2H請(qǐng)求之前，保證不會(huì)從主機(jī)接收任何監(jiān)聽(tīng)。

下表是D2H請(qǐng)求與對(duì)應(yīng)的H2D響應(yīng)（非設(shè)備掛載內(nèi)存）

下表是D2H請(qǐng)求與對(duì)應(yīng)的響應(yīng)（設(shè)備掛載內(nèi)存）

3.2.4.2 D2H響應(yīng)

D2H響應(yīng)編碼：

Rs pIHitI：這是設(shè)備對(duì)主機(jī)的監(jiān)聽(tīng)請(qǐng)求的響應(yīng)，表示在設(shè)備端沒(méi)有此緩存行副本。如果設(shè)備返回RspIHitI，主機(jī)可以認(rèn)為該緩存行已從設(shè)備中清除。

RspVHitV：這是設(shè)備對(duì)主機(jī)的監(jiān)聽(tīng)請(qǐng)求的響應(yīng)，表示在設(shè)備端有此緩存行副本，但是狀態(tài)沒(méi)有改變。如果設(shè)備返回RspVHitV，主機(jī)可以認(rèn)為設(shè)備至少有一個(gè)該緩存行的副本。

RspIHitSE：這是設(shè)備對(duì)主機(jī)的監(jiān)聽(tīng)請(qǐng)求的響應(yīng)，表示在設(shè)備端該緩存行是干凈的，而且現(xiàn)在無(wú)效了。如果設(shè)備返回RspIHitSE，主機(jī)可以認(rèn)為該緩存行已經(jīng)從設(shè)備清掉了。

RspSHitSE：這是設(shè)備對(duì)主機(jī)的監(jiān)聽(tīng)請(qǐng)求的響應(yīng)，表示在設(shè)備端該緩存行是干凈的，而且現(xiàn)在降級(jí)為Shared。如果設(shè)備返回RspSHitSE，主機(jī)將認(rèn)為此緩存行副本還保留在設(shè)備中。

RspSFwdM：H2D的監(jiān)聽(tīng)請(qǐng)求命中的緩存行是Modified狀態(tài)，之后變?yōu)榱薙hared狀態(tài)。設(shè)備可以將狀態(tài)變?yōu)镮nvalid。設(shè)備會(huì)通過(guò)D2H CXL.cache數(shù)據(jù)通道發(fā)送64-byte給主機(jī)。

RspIFwdM：H2D的監(jiān)聽(tīng)請(qǐng)求命中的緩存行是Modified狀態(tài)，之后變?yōu)榱薎nvalid狀態(tài)。主機(jī)可以認(rèn)為設(shè)備不再有該緩存行的副本。設(shè)備會(huì)通過(guò)D2H CXL.cache數(shù)據(jù)通道發(fā)送64-byte給主機(jī)。

RspVFwdV：緩存行的狀態(tài)沒(méi)有發(fā)生變化。設(shè)備僅把當(dāng)前的數(shù)據(jù)發(fā)送給主機(jī)。

3.2.4.3 H2D請(qǐng)求

下圖是H2D監(jiān)聽(tīng)完成的過(guò)程。主機(jī)可以按照與數(shù)據(jù)消息的任何相對(duì)順序接收響應(yīng)消息。對(duì)于監(jiān)聽(tīng)數(shù)據(jù)傳輸，字節(jié)啟用字段始終為1，也就是全部啟用。

H2D請(qǐng)求和相關(guān)的響應(yīng)：

SnpData：主機(jī)發(fā)起的監(jiān)聽(tīng)請(qǐng)求，主機(jī)想將這條緩存行狀態(tài)修改為Shared或者是Exclusive。設(shè)備響應(yīng)一般發(fā)送數(shù)據(jù)。設(shè)備接到該請(qǐng)求后，必須無(wú)效掉自己的副本或者降級(jí)修改狀態(tài)為Shared。如果設(shè)備修改過(guò)此緩存行，必須把“臟”數(shù)據(jù)發(fā)送給主機(jī)。

SnpInv：主機(jī)發(fā)起的監(jiān)聽(tīng)請(qǐng)求，主機(jī)想擁有這條緩存行的所有權(quán)，狀態(tài)修改為Exclusive。這種請(qǐng)求一般是由于主機(jī)要對(duì)該緩存行進(jìn)行寫(xiě)操作。如果設(shè)備內(nèi)有“臟”數(shù)據(jù)，那么必須將該數(shù)據(jù)返回給host。

SnpCur：該監(jiān)聽(tīng)請(qǐng)求是為了獲得最新的緩存行數(shù)據(jù)，但是并不改變它的現(xiàn)有狀態(tài)。如果設(shè)備中的緩存數(shù)據(jù)處于Modified狀態(tài)，必須返回一份數(shù)據(jù)給主機(jī)。主機(jī)和設(shè)備兩端的緩存行狀態(tài)不需要改變，主機(jī)不更新緩存。

3.2.4.4 H2D響應(yīng)

H2D響應(yīng)編碼：

WritePull：主機(jī)告訴設(shè)備，把數(shù)據(jù)發(fā)給主機(jī)，但是不用改變緩存行的狀態(tài)。用于WrInv請(qǐng)求，該消息需要先于GO-I消息發(fā)出，因?yàn)镚O-I消息發(fā)出，意味著I/O的寫(xiě)操作已經(jīng)完成。

GO：（Global Observation）表示讀請(qǐng)求是一致的，寫(xiě)請(qǐng)求是一致的，連貫的。系統(tǒng)設(shè)備已觀察到該事務(wù)，RspType字段中編碼的MESI狀態(tài)表示與該事務(wù)相關(guān)的數(shù)據(jù)應(yīng)置于請(qǐng)求者緩存的哪個(gè)狀態(tài)。

GO_WritePull：這是GO+WritePull消息。沒(méi)有緩存狀態(tài)需要傳輸給設(shè)備。GO+WritePull消息用于posted寫(xiě)類型

ExtCmp：系統(tǒng)觀察到了有Fast_GO數(shù)據(jù)。訪問(wèn)存儲(chǔ)會(huì)得到最新的數(shù)據(jù)

GO_WritePull_Drop：此消息的語(yǔ)義與Go_WritePull相同，只是設(shè)備不應(yīng)向主機(jī)發(fā)送數(shù)據(jù)。當(dāng)主機(jī)確定不需要數(shù)據(jù)時(shí)，可以發(fā)送此響應(yīng)來(lái)代替GO_WritePull。由于始終需要傳輸字節(jié)啟用，因此不會(huì)為部分寫(xiě)入發(fā)送此響應(yīng)

Fast_GO：與GO消息類似，區(qū)別是，該消息意味著只有本地知道了，而GO消息是全系統(tǒng)知道了。當(dāng)事務(wù)是完全可觀測(cè)的時(shí)候，在該消息后面會(huì)發(fā)出ExtCmp消息。如果設(shè)備不支持該消息，則忽略這條消息，一直等待ExtCmp消息。

Fast_GO_WritePull：與GO_WritePull類似，但是該消息告訴設(shè)備，請(qǐng)求只是被本地觀測(cè)到。當(dāng)事務(wù)是完全可觀測(cè)的時(shí)候，在該消息后面會(huì)發(fā)出ExtCmp消息。如果設(shè)備不支持該消息，則忽略這條消息，一直等待ExtCmp消息。主機(jī)不需要傳輸緩存狀態(tài)給設(shè)備。

GO_ERR_WritePull：與GO_WritePull類似，但該消息是告訴設(shè)備，請(qǐng)求出現(xiàn)了錯(cuò)誤，需要設(shè)備去處理。對(duì)于WritePull，設(shè)備一定要把數(shù)據(jù)發(fā)送給主機(jī)，主機(jī)會(huì)將該數(shù)據(jù)丟棄。主機(jī)不需要傳輸緩存狀態(tài)給設(shè)備。

3.2.5 可緩存性詳述和請(qǐng)求限制

本小節(jié)的細(xì)節(jié)和限制適用于所有的設(shè)備。

3.2.5.1 GO-M響應(yīng)

主機(jī)的GO-M響應(yīng)表明設(shè)備被授予修改數(shù)據(jù)（modified data）的唯一副本。設(shè)備必須緩存此數(shù)據(jù)，并在完成后將其寫(xiě)回。

3.2.5.2 Device/Host Snoop-GO-Data假設(shè)

當(dāng)主機(jī)向設(shè)備返回GO響應(yīng)時(shí)，期望到達(dá)接收GO的請(qǐng)求的相同地址的監(jiān)聽(tīng)將看到該GO的結(jié)果。例如，如果主機(jī)發(fā)送GO-E請(qǐng)求RdOwn，然后緊接著向同一地址發(fā)送監(jiān)聽(tīng)，接下來(lái)會(huì)期望設(shè)備將緩存行轉(zhuǎn)換為M狀態(tài)，并且返回RspIFwdM響應(yīng)給主機(jī)。為了實(shí)現(xiàn)這一目的，CXL.cache鏈路層確保設(shè)備將接收這兩條消息，以使順序完全明確。當(dāng)主機(jī)向設(shè)備發(fā)送監(jiān)聽(tīng)請(qǐng)求時(shí)，要求在主機(jī)收到監(jiān)聽(tīng)響應(yīng)并收到所有隱式寫(xiě)回（implicit writeback，IWB）數(shù)據(jù)之前，不會(huì)向設(shè)備中含有該地址的任何請(qǐng)求發(fā)送GO響應(yīng)。當(dāng)主機(jī)向設(shè)備返回?cái)?shù)據(jù)，并且該請(qǐng)求的GO尚未發(fā)送到設(shè)備時(shí)，主機(jī)可能在發(fā)送GO消息之前不會(huì)向該地址發(fā)送監(jiān)聽(tīng)請(qǐng)求。

從根本上講，與讀取請(qǐng)求相關(guān)的GO也適用于該請(qǐng)求返回的數(shù)據(jù)。為讀取請(qǐng)求發(fā)送數(shù)據(jù)意味著數(shù)據(jù)有效，這意味著即使GO尚未到達(dá)，設(shè)備也可以使用它。

3.2.5.3 Device/Host Snoop/WritePull假設(shè)

在主機(jī)收到來(lái)自64字節(jié)地址的所有WritePull數(shù)據(jù)之前，主機(jī)不可以對(duì)該地址啟動(dòng)監(jiān)聽(tīng)。相反，在主機(jī)收到對(duì)掛起的寫(xiě)入地址監(jiān)聽(tīng)的響應(yīng)之前，主機(jī)不可以啟動(dòng)WritePull。

1.2.5.4?CXL.cache上逐出（Evicts）的監(jiān)聽(tīng)響應(yīng)和數(shù)據(jù)傳輸

如果已在CXL.cache D2H請(qǐng)求通道上發(fā)出設(shè)備逐出事務(wù)，但尚未從主機(jī)收到WritePull，并且監(jiān)聽(tīng)命中WB，則設(shè)備必須跟蹤此監(jiān)聽(tīng)命中。當(dāng)設(shè)備開(kāi)始處理WritePull時(shí)，設(shè)備必須在發(fā)送到主機(jī)的所有D2H數(shù)據(jù)消息中設(shè)置Bogus字段。目的是向主機(jī)傳達(dá)請(qǐng)求數(shù)據(jù)已作為IWB數(shù)據(jù)發(fā)送，因此逐出的數(shù)據(jù)可能已過(guò)時(shí)。

3.2.5.5 對(duì)相同地址的多個(gè)監(jiān)聽(tīng)

只允許主機(jī)在某一時(shí)刻對(duì)指定設(shè)備的指定緩存行地址有一個(gè)未完成監(jiān)聽(tīng)。也就是說(shuō)，主機(jī)必須等到接收到監(jiān)聽(tīng)響應(yīng)和所有IWB數(shù)據(jù)（如果有）后，才能將下一個(gè)監(jiān)聽(tīng)請(qǐng)求發(fā)送到該地址。

3.2.5.6 對(duì)同一緩存行的多個(gè)讀請(qǐng)求

只有在以下特定情況下，才允許對(duì)同一緩存行執(zhí)行多個(gè)讀請(qǐng)求。

3.2.5.7 對(duì)同一緩存行的多個(gè)逐出

不允許對(duì)同一緩存行發(fā)起多次逐出請(qǐng)求。

3.2.5.8 對(duì)同一緩存行的多個(gè)寫(xiě)請(qǐng)求

允許在CXL.cache上對(duì)同一緩存行執(zhí)行多個(gè)WrInv/WOWrInv/ItoMWr/MemWr。主機(jī)或交換機(jī)可以自由的進(jìn)行重新排序請(qǐng)求，并且設(shè)備按照重新排序的順序接收相應(yīng)的H2D響應(yīng)。但是，通常不建議設(shè)備對(duì)同一緩存行發(fā)出多個(gè)寫(xiě)請(qǐng)求。

3.2.5.9 GO

只有在主機(jī)保證請(qǐng)求將擁有緩存行的所有權(quán)之后，才會(huì)發(fā)送GO響應(yīng)。

3.2.5.10 FastGO

FastGO只允許用于不需要嚴(yán)格排序的請(qǐng)求。

3.2.5.11 逐出到設(shè)備掛載的內(nèi)存

設(shè)備僅允許向設(shè)備掛載的內(nèi)存發(fā)出WrInv和WOWrInv*。

3.2.5.12 CXL.cache上的內(nèi)存類型

要在CXL.cache上發(fā)出請(qǐng)求，設(shè)備需要通過(guò)CXL.io上的ATS請(qǐng)求從主機(jī)獲取主機(jī)物理地址。

編輯：黃飛

閱讀全文

數(shù)據(jù)傳輸(63497) 數(shù)據(jù)傳輸(63497)

評(píng)論

相關(guān)推薦

正在為服務(wù)器市場(chǎng)創(chuàng)造數(shù)十億價(jià)值的CXL

Infinity架構(gòu)為例，AMD計(jì)劃將其CPU、GPU、FPGA與3D V-Cache都放在同一個(gè)框架內(nèi)，并利用基于CXL 2.0的內(nèi)存來(lái)完成分解，讓整個(gè)系統(tǒng)從計(jì)算、內(nèi)存到存儲(chǔ)都能自由組合。 ? CXL聯(lián)盟董事成員 / CXL聯(lián)盟 ? 為了進(jìn)一步推廣并維護(hù)這一標(biāo)準(zhǔn)，CXL聯(lián)盟誕生了。從2019年到現(xiàn)在，該聯(lián)

2022-06-30 08:03:00

3639

先詳解CXL系統(tǒng)架構(gòu)

CXL設(shè)備擴(kuò)展限制只允許每個(gè)VH（Virtual Hierarchy）啟用一個(gè)Type 1或Type 2設(shè)備。

2022-09-14 09:10:25

5611

基于CXL的直接訪問(wèn)高性能內(nèi)存分解框架

鑒于KAIST的HPC根源，將DirectCXL原型放在一起的研究人員專注于使用遠(yuǎn)程直接內(nèi)存訪問(wèn)（RDMA）協(xié)議將CXL內(nèi)存池與跨系統(tǒng)直接內(nèi)存訪問(wèn)進(jìn)行比較。

2022-09-23 10:50:26

1102

Arm Cortex-A53 cache的架構(gòu)解析

A53的L1 Data cache遵從的是MOESI協(xié)議，如下所示在L1 data cache的tag中存有MOESI的標(biāo)記位。

2023-09-01 15:01:21

5025

什么是CXL？一文了解高速互聯(lián)技術(shù)CXL

Compute Express Link（CXL）作為一種先進(jìn)的互連技術(shù)，在當(dāng)今高性能計(jì)算領(lǐng)域引起了廣泛關(guān)注

2023-11-29 15:26:33

801

利用CXL技術(shù)重構(gòu)基于RDMA的內(nèi)存解耦合

本文提出了一種基于RDMA和CXL的新型低延遲、高可擴(kuò)展性的內(nèi)存解耦合系統(tǒng)Rcmp。其顯著特點(diǎn)是通過(guò)CXL提高了基于RDMA系統(tǒng)的性能，并利用RDMA克服了CXL的距離限制。

2024-02-29 10:05:40

333

6678多核之間的L1 CACHE一致性是由硬件實(shí)現(xiàn)的嗎

工程師您好！按照6678文檔上所講，每個(gè)core都有一個(gè)L1D cache和L1P cache，那么這八個(gè)核之間的L1 CACHE是會(huì)存在一致性的，那么這樣的一致性是由硬件實(shí)現(xiàn)的還是需要程序員用軟件實(shí)現(xiàn)呢？謝謝！

2018-12-25 11:25:43

CXL1517

CXL1517 - CMOS-CCD Signal Processor - Sony Corporation

2022-11-04 17:22:44

CXL1518M

CXL1518M - CMOS-CCD Signal Processor - Sony Corporation

2022-11-04 17:22:44

CXL9910恒流非隔離PWM線性調(diào)光LED驅(qū)動(dòng)IC

本帖最后由 qq854236200 于 2018-3-20 15:49 編輯 CXL9910一款高效的PWM LED恒流驅(qū)動(dòng)應(yīng)用設(shè)計(jì)使用IC，輸入電壓可以市電直接整流濾波供電，450V DC

2017-08-01 11:43:00

CXL事務(wù)層學(xué)習(xí)相關(guān)資料推薦

1、CXL事務(wù)層學(xué)習(xí)　　CXL.cache協(xié)議將設(shè)備和主機(jī)之間的交互定義為多個(gè)請(qǐng)求，每個(gè)請(qǐng)求至少有一條相關(guān)的響應(yīng)消息，有時(shí)還有數(shù)據(jù)傳輸。該接口在每個(gè)方向上由三個(gè)通道組成：請(qǐng)求（Request）、響應(yīng)

2022-10-18 14:19:02

CXL事務(wù)層的結(jié)構(gòu)是由哪些部分組成的

3.1 CXL.ioCXL.io為IO設(shè)備提供非一致性的load/strore接口。事務(wù)類型、事務(wù)數(shù)據(jù)包格式、信用流量控制、虛擬通道管理、事務(wù)順序的規(guī)則等遵循PCIe協(xié)議。CXL.io的事務(wù)層如下

2022-10-08 15:21:40

CXL內(nèi)存協(xié)議介紹

CXL.mem從設(shè)備（Subordinate）。主設(shè)備負(fù)責(zé)向從設(shè)備發(fā)起讀寫(xiě)請(qǐng)求，從設(shè)備負(fù)責(zé)響應(yīng)主設(shè)備的讀寫(xiě)請(qǐng)求。當(dāng)從設(shè)備是一個(gè)加速器時(shí)，CXL.mem協(xié)議認(rèn)為設(shè)備內(nèi)部也有一個(gè)一致性引擎（Device

2022-11-01 15:08:12

Cache為什么還要分I-Cache，D-Cache，L2 Cache，作用是什么？

Cache為什么還要分I-Cache，D-Cache，L2 Cache，作用是什么？

2023-10-25 06:38:45

cache 問(wèn)題

cache到 ?ddr里面的數(shù)據(jù)呢？還是數(shù)據(jù)自動(dòng)cache到L1D里面呢？能不能詳細(xì)解釋一下cache的工作原理！期待您的答復(fù)！謝謝！

2018-06-21 15:10:16

一文詳解CXL鏈路層格式的定義

共用的鏈路層4.2.1 介紹CXL.mem和CXL.cache共用同一個(gè)鏈路層，下圖中的黃色區(qū)域。4.2.2 高層次CXL.cache/CXL.mem Flit概述CXL.cache/CXL

2023-02-21 14:27:46

一文看懂LoraNET協(xié)議

套通訊協(xié)議和系統(tǒng)架構(gòu)，是一種媒體訪問(wèn)控制（MAC）層協(xié)議。Lora無(wú)線通訊經(jīng)過(guò)幾年的應(yīng)用時(shí)間，在全球出貨已經(jīng)上億萬(wàn)片。目前市面上的LoRa協(xié)議各式各樣，LoraWAN、CLAA、LinkWAN都各有不同

2020-12-13 21:47:48

一文解析CXL系統(tǒng)架構(gòu)

1、CXL系統(tǒng)架構(gòu)簡(jiǎn)析　　CXL支持三種設(shè)備類型，如下圖。Type 1支持CXL.cache和CXL.io；Type2支持CXL.cache，CXL.mem和CXL.io；Type3支持

2022-09-14 14:24:52

一文讀懂什么是NEC協(xié)議

一文讀懂什么是NEC協(xié)議？

2021-10-15 09:22:14

一窺CXL協(xié)議

系統(tǒng)存儲(chǔ)。其中CXL.cache和CXL.memory是備選的。三種 CXL 協(xié)議分別對(duì)應(yīng)一個(gè)接口。如上圖中，右側(cè)的主機(jī)可以通過(guò)CXL連接左側(cè)的加速芯片，其中CXL.io擴(kuò)展外部I/O設(shè)備

2022-09-09 15:03:06

AXI接口協(xié)議詳解

1、AXI接口協(xié)議詳解　　AXI 總線　　上面介紹了AMBA總線中的兩種，下面看下我們的主角—AXI，在ZYNQ中有支持三種AXI總線，擁有三種AXI接口，當(dāng)然用的都是AXI協(xié)議。其中三種AXI總線

2022-10-14 15:31:40

CANOPEN協(xié)議詳解

2016-09-20 16:00:37

DirectCXL內(nèi)存分解原型設(shè)計(jì)實(shí)現(xiàn)

鑒于KAIST的HPC根源，將DirectCXL原型放在一起的研究人員專注于使用遠(yuǎn)程直接內(nèi)存訪問(wèn)（RDMA）協(xié)議將CXL內(nèi)存池與跨系統(tǒng)直接內(nèi)存訪問(wèn)進(jìn)行比較。他們使用了一個(gè)非常老式的Mellanox

2022-11-15 11:14:59

FAT32文件系統(tǒng)詳解

2016-08-17 12:34:56

LwIP協(xié)議棧源碼詳解

2012-08-20 23:17:01

NE555中文資料詳解

2012-08-20 13:49:07

NE555中文資料詳解

2012-08-21 09:27:19

NE555中文資料詳解

2012-11-23 22:08:18

RTSP協(xié)議詳解與實(shí)時(shí)流簡(jiǎn)要介紹

RTSP協(xié)議詳解與實(shí)時(shí)流視頻預(yù)覽-第6/11季視頻課程-海思互聯(lián)網(wǎng)課程品牌...

2021-12-23 07:03:19

STM32WB產(chǎn)品詳解及FUS無(wú)線協(xié)議棧升級(jí)

STM32WB產(chǎn)品詳解及FUS無(wú)線協(xié)議棧升級(jí)2.4GHz無(wú)線雙核STM32WB, 采用SoC單芯片設(shè)計(jì)，支持多協(xié)議射頻。

2023-09-06 06:35:56

TCPIP詳解卷1協(xié)議

2016-09-28 12:45:39

TCPIP詳解卷三：TCP事務(wù)協(xié)議,HTTP,NNTP和UNIX域協(xié)議

TCPIP詳解卷三：TCP事務(wù)協(xié)議,HTTP,NNTP和UNIX域協(xié)議

2016-09-28 12:45:11

modbus協(xié)議講解modbus-rtu以及modbus-tcp協(xié)議詳解

modbus協(xié)議講解modbus-rtu以及modbus-tcp協(xié)議詳解，見(jiàn)附件。

2020-03-01 10:14:57

u*2.0中文協(xié)議**下載

u***2.0中文協(xié)議下載·該規(guī)范主要面向外設(shè)開(kāi)發(fā)商和系統(tǒng)生產(chǎn)商。并且提供了許多有價(jià)值的信息給操作系統(tǒng)/BIOS/設(shè)備驅(qū)動(dòng)平臺(tái)、IHVS/ISVS 適配器，以及各種計(jì)算機(jī)生產(chǎn)廠家使用?！ぴ揢SB

2008-06-16 15:07:24

為什么需要cache？cache是如何影響code的呢

; j++) arr[j] = 1;功能完全一樣，但是我們一直在重復(fù)著第一種寫(xiě)法（或許很多的書(shū)中也是建議這么編碼），你是否想過(guò)這其中的緣由？文章的主角是cache，所以你一定猜到了答案。那么cache

2022-04-21 11:10:49

介紹一種多級(jí)cache的包含策略（Cache inclusion policy）

設(shè)計(jì)多級(jí)cache可以有很多種方式，可以根據(jù)一個(gè)cache的內(nèi)容是否同時(shí)存在于其他級(jí)cache來(lái)分類，即Cache inclusion policy。如果較低級(jí)別cache中的所有cacheline

2022-07-20 14:46:15

關(guān)于cache和cache_line的一個(gè)概念問(wèn)題

幫忙給解答一下一個(gè)基本概念，cpu在訪問(wèn)數(shù)據(jù)時(shí)，如果數(shù)據(jù)不在L1D和L2中，就需要從DDR等外設(shè)中取數(shù)，文獻(xiàn)中說(shuō)過(guò)，“cache會(huì)prefetch讀取cache_line長(zhǎng)度的地址，保證連續(xù)的地址上

2018-06-21 17:31:26

商用車1939協(xié)議詳解

商用車1939協(xié)議詳解，吉林大學(xué)汽車車底盤(pán)國(guó)家重點(diǎn)實(shí)驗(yàn)室的教程。

2015-09-20 19:46:03

大彩串口屏可以兼容迪文DGUS協(xié)議嗎？

之前用的是迪文屏，開(kāi)發(fā)不太方便，現(xiàn)在改用大彩的屏，不知道大彩的屏幕可以兼容迪文dgus協(xié)議嗎？有沒(méi)有人知道

2019-05-09 17:09:30

裸跑LWIP協(xié)議棧的cache怎么使用？

來(lái)保證數(shù)據(jù)正常傳輸！當(dāng)不使用cache時(shí)，以太網(wǎng)是可以正常收發(fā)的!但是一使用cache收發(fā)數(shù)據(jù)就不正常！在emac中斷中怎樣使用cache，這些有沒(méi)有例程可以參考，謝謝！

2019-10-21 06:53:39

迪文屏可以接收用戶通訊協(xié)議？

請(qǐng)問(wèn)各位大咖：迪文屏能接收用戶MCU的串口協(xié)議嗎？如何做？請(qǐng)您指教！

2022-01-27 06:18:29

《TCP-IP詳解_卷3_TCP事務(wù)協(xié)議,HTTP,NNTP

《TCP-IP詳解_卷3_TCP事務(wù)協(xié)議,HTTP,NNTP和UNIX域協(xié)議》

2006-03-24 22:42:49

《TCP-IP詳解_卷1_協(xié)議》

2006-03-24 22:45:40

改進(jìn)的基于目錄的Cache一致性協(xié)議

介紹幾種典型目錄一致性協(xié)議并分析它們的優(yōu)缺點(diǎn)。在綜合全映射目錄和有限目錄優(yōu)點(diǎn)的基礎(chǔ)上，通過(guò)在存儲(chǔ)器層上增加一個(gè)存儲(chǔ)器高速緩存(Cache)層的方式，提出并討論一種改進(jìn)后

2009-04-02 09:05:00

OSPF協(xié)議詳解

OSPF協(xié)議詳解:OSPF協(xié)議概述，OSPF的鄰居狀態(tài)機(jī)，OSPF與路由自環(huán)，OSPF調(diào)試與監(jiān)控，OSPF排錯(cuò)，OSPF的trouble shooting。

2009-09-09 22:20:04

Cache中Tag電路的設(shè)計(jì)

摘要：在SoC系統(tǒng)中，片上緩存(Cache)的采用是解決片上處理器和片外存儲(chǔ)器之間速度差異的重要方法，Cache中用來(lái)存儲(chǔ)標(biāo)記位并判斷Cache是否命中的Tag電路的設(shè)計(jì)將會(huì)影響到整個(gè)Cache的

2010-05-08 09:26:24

tcp ip協(xié)議詳解卷三下載

tcp ip協(xié)議詳解卷三:第三卷的內(nèi)容細(xì)節(jié)覆蓋了當(dāng)今TCP/IP編程人員和網(wǎng)絡(luò)管理員必須熟練掌握的四個(gè)基本方面： T/TCP (TCP事務(wù)協(xié)議),這是對(duì)TCP的擴(kuò)展，使客戶--服務(wù)器間

2010-05-19 11:52:06

437

tcp ip協(xié)議詳解卷二

tcp ip協(xié)議詳解卷二:第13章IGMP：Internet組管理協(xié)議13.1 引言I G M P在本地網(wǎng)絡(luò)上的主機(jī)和路由器之間傳達(dá)組成員信息。路由器定時(shí)向“所有主機(jī)組”多播I G M P查詢。主機(jī)多播I G M P

2010-05-19 12:00:06

542

tcp ip協(xié)議詳解卷一

tcp ip協(xié)議詳解卷一:《TCP/IP詳解，卷1：協(xié)議》是一本完整而詳細(xì)的TCP/IP協(xié)議指南。描述了屬于每一層的各個(gè)協(xié)議以及它們?nèi)绾卧诓煌僮飨到y(tǒng)中運(yùn)行。作者用Lawrence Berkeley實(shí)驗(yàn)室的tcpd

2010-05-19 12:02:19

711

CMP中Cache一致性協(xié)議的驗(yàn)證

CMP是處理器體系結(jié)構(gòu)發(fā)展的一個(gè)重要方向，其中Cache一致性問(wèn)題的驗(yàn)證是CMP設(shè)計(jì)中的一項(xiàng)重要課題?；贛ESI一致性協(xié)議，本文建立了CMP的Cache一致性協(xié)議的驗(yàn)證模型，總結(jié)了三種驗(yàn)證

2010-07-20 14:18:27

什么是Cache/SIMD?

什么是Cache/SIMD? 　 Cache ：即高速緩沖存儲(chǔ)器，是位于CPU與主內(nèi)存間的一種容量較小但速度很高的存儲(chǔ)器。由于CPU的速度遠(yuǎn)高于主內(nèi)存

2010-02-04 11:29:44

515

什么是Cache

什么是Cache 英文縮寫(xiě): Cache 中文譯名: 高速緩存器分　　類: IP與多媒體解　　釋: 信息在本地的臨時(shí)存儲(chǔ)

2010-02-22 17:26:39

948

高速緩存(Cache),高速緩存(Cache)原理是什么?

高速緩存(Cache),高速緩存(Cache)原理是什么? 高速緩存Cache是位于CPU和主存儲(chǔ)器之間規(guī)模較小、存取速度快捷的靜態(tài)存儲(chǔ)器。Cache一般由

2010-03-26 10:49:27

6717

cache基本知識(shí)培訓(xùn)教程[2]

cache基本知識(shí)培訓(xùn)教程[2] 相聯(lián)度越高（即 n 的值越大）， Cache 空間的利用率就越高，塊沖突概率就越低，因而 Cache 的失效率就越低。塊沖突是指一

2010-04-13 16:25:37

1982

Modbus通信協(xié)議詳解

關(guān)于Modbus通信協(xié)議的詳解和應(yīng)用分析

2011-10-12 16:54:49

148

路由協(xié)議的分類和作用詳解

介紹關(guān)于路由協(xié)議的概念、原理，路由協(xié)議的分類和作用詳解。

2011-11-03 15:08:50

9474

RS232協(xié)議標(biāo)準(zhǔn)詳解

網(wǎng)上收集下載的資料，RS232協(xié)議標(biāo)準(zhǔn)詳解，相信大家有用的。

2015-11-04 16:27:02

LwIP協(xié)議詳解

LwIP協(xié)議詳解，LwIP是Light Weight (輕型)IP協(xié)議，有無(wú)操作系統(tǒng)的支持都可以運(yùn)行。LwIP實(shí)現(xiàn)的重點(diǎn)是在保持TCP協(xié)議主要功能的基礎(chǔ)上減少對(duì)RAM 的占用，它只需十幾KB的RAM和40K左右的ROM就可以運(yùn)行，這使LwIP協(xié)議棧適合在低端的嵌入式系統(tǒng)中使用。

2015-11-09 18:25:20

Modbus_通訊協(xié)議詳解

Modbus_通訊協(xié)議詳解，Modbus_通訊協(xié)議詳解

2015-12-08 14:13:12

一種基于貝葉斯網(wǎng)絡(luò)的隨機(jī)測(cè)試方法在Cache一致性驗(yàn)證中的設(shè)計(jì)與實(shí)現(xiàn)

隨著集成電路設(shè)計(jì)復(fù)雜度指數(shù)級(jí)增長(zhǎng)，功能驗(yàn)證已經(jīng)越來(lái)越成為大規(guī)模芯片設(shè)計(jì)的瓶頸，而在多核處理器中，Cache -致性協(xié)議十分復(fù)雜，驗(yàn)證難度大。針對(duì)Cache -致性協(xié)議驗(yàn)證提出基于模擬驗(yàn)證的一種

2017-11-17 17:24:07

Intel宣布聯(lián)合多家廠商推出全新互聯(lián)協(xié)議并發(fā)布CXL1.0規(guī)范

處理器大廠英特爾（Intel）宣布聯(lián)合多家廠商，一起推出了針對(duì)資料中心、高效能計(jì)算、AI 等領(lǐng)域的全新的互聯(lián)協(xié)議 Compute EXpress Link（CXL），并將正式發(fā)布 CXL 1.0 規(guī)范。

2019-03-13 17:03:11

2792

cache結(jié)構(gòu)與工作原理

更詳細(xì)的講，cache的結(jié)構(gòu)其實(shí)和內(nèi)存的結(jié)構(gòu)類似，也包含地址和內(nèi)容，只是cache的內(nèi)容除了存的數(shù)據(jù)（data）之外，還包含存的數(shù)據(jù)的物理內(nèi)存的地址信息（tag），因?yàn)镃PU發(fā)出的尋址信息都是針對(duì)

2019-06-03 14:24:13

10854

DesignWare CXL為SoC提供優(yōu)化的多芯片IP堆棧

● DesignWare CXL IP 支持 AMBA CXS 協(xié)議，以實(shí)現(xiàn)與可擴(kuò)展 Arm Neoverse 相干網(wǎng)狀網(wǎng)絡(luò)的無(wú)縫集成 ● 新思科技 CXL IP 以 32GT/s 的速度運(yùn)行，數(shù)據(jù)

2020-10-27 16:40:28

1477

廠商基于CXL上面做文章的案例

最近有幾個(gè)熱點(diǎn)事件發(fā)生了，好像都跟CXL有關(guān)，小編前年也關(guān)注到這一點(diǎn)了，可以看下這篇文章“CXL高速互連技術(shù)成員數(shù)已從9名增加到33名” 美光退出3D Xpoint，移至CXL 首先第一件事大家

2021-04-01 15:48:09

1774

Page Cache是什么一文帶你深入理解Linux的Page Cache

作者：Spongecaptain https://spongecaptain.cool/SimpleClearFileIO/ 1. Page Cache 1.1 Page Cache

2021-10-20 14:12:41

5322

從三個(gè)方面闡述Cache

關(guān)于cache，大概可以從三個(gè)方面進(jìn)行闡述：內(nèi)存到cache的映射方式，cache的寫(xiě)策略，cache的替換策略。映射方式內(nèi)存到cache的映射方式，大致可以分為三種，分別是：直接映射

2021-11-21 11:09:50

2128

FreeSwitch的sip協(xié)議協(xié)議詳解.pdf

FreeSwitch的sip協(xié)議協(xié)議詳解.pdf

2021-12-30 11:28:46

瀾起科技發(fā)布全球首款CXL? 內(nèi)存擴(kuò)展控制器芯片

MXC芯片是一款CXL DRAM內(nèi)存控制器，屬于CXL協(xié)議所定義的第三種設(shè)備類型。該芯片支持JEDEC DDR4和DDR5標(biāo)準(zhǔn)，同時(shí)也符合CXL 2.0規(guī)范，支持PCIe 5.0的速率。

2022-05-06 10:46:43

2174

SMART世邁科技推出首款XMM CXL內(nèi)存模塊

(CXL?)內(nèi)存模塊XMM CXL內(nèi)存模塊。SMART Modular的這款新型 DDR5 XMM CXL 模塊通過(guò)CXL接口增加緩存一致性內(nèi)存，可提升服務(wù)器和數(shù)據(jù)中心的運(yùn)算性能，更能超越現(xiàn)今大多數(shù)服務(wù)器只有 8信道或12信道的限制，進(jìn)一步擴(kuò)展大數(shù)據(jù)處理能力。

2022-09-01 15:38:06

993

CXL的特點(diǎn)和優(yōu)勢(shì)，以及三星CXL存儲(chǔ)器擴(kuò)展器和開(kāi)源CXL軟件

為什么這一點(diǎn)很重要？因?yàn)?，這讓CXL主機(jī)和CXL設(shè)備能夠運(yùn)行和處理共享的數(shù)據(jù)，并能確保在同一存儲(chǔ)器位置讀取相同副本的數(shù)據(jù)。歸屬代理不允許同時(shí)更改數(shù)據(jù)，所以每次（主機(jī)或掛載的設(shè)備）發(fā)起更改時(shí)，歸屬代理都會(huì)確保所有數(shù)據(jù)副本保持一致。

2022-09-06 10:03:32

1229

CXL在PCIe 5.0的基礎(chǔ)上復(fù)用三種類型的協(xié)議

CXL是基于PCIe 5.0實(shí)現(xiàn)的連接技術(shù)，復(fù)用了很多PCIe協(xié)議的東西，這一點(diǎn)上與CCIX比較像，但又不完全一樣。說(shuō)起CCIX和CXL，難免要相互對(duì)比。

2022-09-06 10:05:57

5258

STM32F7 MPU Cache淺析

本文會(huì)從結(jié)構(gòu)，原理以及應(yīng)用方面對(duì) MPU 和 Cache 進(jìn)行分析，主要目的是希望讀者對(duì) Cache 有基本的了解，在具體的實(shí)際應(yīng)用中，使用帶有一級(jí) cache 的 MCU 時(shí)，避免常見(jiàn)的錯(cuò)誤。

2022-09-28 11:05:20

CXL事務(wù)層詳解

CXL.io為IO設(shè)備提供非一致性的load/strore接口。事務(wù)類型、事務(wù)數(shù)據(jù)包格式、信用流量控制、虛擬通道管理、事務(wù)順序的規(guī)則等遵循PCIe協(xié)議。CXL.io的事務(wù)層如下圖中的黃色部分所示。

2022-10-10 16:02:29

2109

AM64x/AM243x多協(xié)議Demo搭建與詳解

AM64x/AM243x多協(xié)議Demo搭建與詳解

2022-10-28 11:59:55

什么是 Cache? Cache讀寫(xiě)原理

由于寫(xiě)入數(shù)據(jù)和讀取指令分別通過(guò) D-Cache 和 I-Cache，所以需要同步 D-Cache 和 I-Cache，即復(fù)制后需要先將 D-Cache 寫(xiě)回到內(nèi)存，而且還需要作廢當(dāng)前的 I-Cache 以確保執(zhí)行的是 Memory 內(nèi)更新的代碼

2022-12-06 09:55:56

1164

CPU Cache偽共享問(wèn)題

當(dāng)CPU想要訪問(wèn)主存中的元素時(shí)，會(huì)先查看Cache中是否存在，如果存在（稱為Cache Hit），直接從Cache中獲取，如果不存在（稱為Cache Miss），才會(huì)從主存中獲取。Cache的處理速度比主存快得多。

2022-12-12 09:17:51

469

基于PCI-e協(xié)議的CXL技術(shù)

CXL是一個(gè)全新的得到業(yè)界認(rèn)同的互聯(lián)技術(shù)標(biāo)準(zhǔn)，其正帶著服務(wù)器架構(gòu)迎來(lái)革命性的轉(zhuǎn)變。

2023-02-02 09:55:35

739

一文讀懂CXL協(xié)議

CXL全稱為Compute Express Link，作為一種全新的開(kāi)放式互聯(lián)技術(shù)標(biāo)準(zhǔn)，其能夠讓CPU與GPU、FPGA或其他加速器之間實(shí)現(xiàn)高速高效的互聯(lián)，從而滿足高性能異構(gòu)計(jì)算的要求，并且其維護(hù)CPU內(nèi)存空間和連接設(shè)備內(nèi)存之間的一致性。總體而言，其優(yōu)勢(shì)高度概括在極高兼容性和內(nèi)存一致性兩方面上。

2023-02-11 11:01:20

1340

什么是CXL協(xié)議

CXL全稱為Compute Express Link，作為一種全新的開(kāi)放式互聯(lián)技術(shù)標(biāo)準(zhǔn)，其能夠讓CPU與GPU、FPGA或其他加速器之間實(shí)現(xiàn)高速高效的互聯(lián)，從而滿足高性能異構(gòu)計(jì)算的要求，并且其維護(hù)CPU內(nèi)存空間和連接設(shè)備內(nèi)存之間的一致性?？傮w而言，其優(yōu)勢(shì)高度概括在極高兼容性和內(nèi)存一致性兩方面上

2023-02-21 15:06:54

1453

CXL協(xié)議和標(biāo)準(zhǔn)介紹， CXL2.0和3.0有什么新功能？

CXL通過(guò)一個(gè)叫做CXL 聯(lián)盟的開(kāi)放行業(yè)標(biāo)準(zhǔn)組織開(kāi)發(fā)技術(shù)規(guī)范，促進(jìn)新興使用模型的性能突破，同時(shí)支持?jǐn)?shù)據(jù)中心加速器和其他高速增強(qiáng)功能的開(kāi)放生態(tài)系統(tǒng)。

2023-03-15 11:30:54

3845

CXL SSD的性能會(huì)與NVMe SSD有何區(qū)別？

CXL和PCIe之間的區(qū)別可能不太明顯。在信號(hào)級(jí)別上，這兩者確實(shí)是相同的，但兩者的協(xié)議不同。CXL選擇比PCIe更快的協(xié)議，盡管CXL.io支持標(biāo)準(zhǔn)的PCIe I/O設(shè)備。

2023-04-11 11:14:02

2141

使用經(jīng)過(guò)驗(yàn)證的CXL IDE構(gòu)建安全芯片

CXL 2.0規(guī)范為 CXL.io 和CXL.cache/CXL.mem協(xié)議引入了IDE原理圖。CXL.io 途徑使用 PCIe 規(guī)范定義的 IDE，而 CXL.cache/CXL.mem 相關(guān)更新在 CXL 2.0 規(guī)范中引入。在本博客中，我們將概述安全設(shè)置的外觀以及 CXL 采用的安全策略。

2023-05-25 16:41:12

837

訪問(wèn)CXL 2.0設(shè)備中的內(nèi)存映射寄存器

計(jì)算快速鏈接（CXL） 1.1 和 CXL 2.0 規(guī)范在內(nèi)存映射寄存器的放置和訪問(wèn)方式上有所不同。CXL 1.1 規(guī)范將內(nèi)存映射寄存器放置在 RCRB（根復(fù)合寄存器塊）中，而 CXL 2.0

2023-05-25 16:56:20

1130

CXL 2.0設(shè)備發(fā)現(xiàn)的迷人路徑

CXL 2.0 規(guī)范在 PCIe 配置空間映射寄存器中定義了多個(gè)新的 PCIe 指定供應(yīng)商特定擴(kuò)展功能（DVSEC）。以下是 CXL 2.0 設(shè)備的一些強(qiáng)制性 DVSEC。

2023-05-25 17:22:06

916

揭開(kāi)CXL的神秘面紗：概述

CXL 是一種在主機(jī)（通常是 CPU）和設(shè)備（通常是附加了內(nèi)存的加速器）之間實(shí)現(xiàn)高帶寬、低延遲鏈接的技術(shù)。CXL 堆棧專為低延遲而設(shè)計(jì)，使用 PCIe 電氣和附加卡的標(biāo)準(zhǔn) PCIe 外形規(guī)格。CXL 使用靈活的處理器端口，可以自動(dòng)協(xié)商到標(biāo)準(zhǔn) PCIe 事務(wù)協(xié)議或備用 CXL 事務(wù)協(xié)議。

2023-05-26 10:33:11

3266

深入理解Cache工作原理

按照數(shù)據(jù)關(guān)系劃分：Inclusive/exclusive Cache: 下級(jí)Cache包含上級(jí)的數(shù)據(jù)叫inclusive Cache。不包含叫exclusive Cache。舉個(gè)例子，L3 Cache里有L2 Cache的數(shù)據(jù)，則L2 Cache叫exclusive Cache。

2023-05-30 16:02:34

418

瀾起科技MXC芯片成功通過(guò)CXL聯(lián)盟組織的CXL1.1合規(guī)測(cè)試

。 ? ?? CXL，全稱為Compute Express Link，是一種全新的高速互連協(xié)議，旨在提升人工智能、大數(shù)據(jù)等內(nèi)存密集型工作負(fù)載的數(shù)據(jù)傳輸和處理性能。通過(guò)CXL聯(lián)盟的合規(guī)測(cè)試，是檢驗(yàn)CXL生態(tài)系統(tǒng)內(nèi)各產(chǎn)品部件包括CPU、CXL設(shè)備、加速器等是否合乎CXL規(guī)范的關(guān)鍵，也是CXL生態(tài)系統(tǒng)內(nèi)部實(shí)現(xiàn)互操

2023-08-18 09:14:38

703

瀾起科技MXC芯片率先列入CXL官網(wǎng)的合規(guī)供應(yīng)商清單

Integrators List)。瀾起科技是全球首家進(jìn)入CXL合規(guī)供應(yīng)商清單的MXC芯片廠家。 CXL?，全稱為Compute Express Link?，是一種全新的高速互連協(xié)議，旨在提升人工智能、大數(shù)據(jù)等內(nèi)存

2023-08-22 05:11:58

437

在組相聯(lián)cache中，用于替換cache line的算法有哪些？

LRU(Least Recently Used)算法：該算法會(huì)跟蹤每個(gè)cache line的age(年齡)情況，并在需要時(shí)替換掉近期最少使用的cache line。

2023-10-08 11:10:05

433

CXL技術(shù)的三種模式 CXL技術(shù)與其他技術(shù)的對(duì)比

CXL的目標(biāo)：解決CPU和設(shè)備、設(shè)備和設(shè)備之間的內(nèi)存鴻溝。服務(wù)器有巨大的內(nèi)存池和數(shù)量龐大的基于PCIe運(yùn)算加速器，每個(gè)上面都有很大的內(nèi)存。內(nèi)存的分割已經(jīng)造成巨大的浪費(fèi)、不便和性能下降。CXL就是為解決這個(gè)問(wèn)題而誕生。

2023-10-30 14:30:31

3135

Cache的原理和地址映射

在cache存儲(chǔ)系統(tǒng)中，把cache和主存儲(chǔ)器都劃分成相同大小的塊。主存地址由塊號(hào)B和塊內(nèi)地址W兩部分組成，cache地址由塊號(hào)b和塊內(nèi)地址w組成。當(dāng)CPU訪問(wèn)cache時(shí)，CPU送來(lái)主存地址

2023-10-31 11:21:36

453

Cache分類與替換算法

根據(jù)不同的分類標(biāo)準(zhǔn)可以按以下3種方法對(duì)Cache進(jìn)行分類。 ?1）數(shù)據(jù)cache和指令cache ?● 指令cache：指令預(yù)取時(shí)使用的cache。 ?● 數(shù)據(jù)cache：數(shù)據(jù)讀寫(xiě)時(shí)使用的cache

2023-10-31 11:26:31

372

Cache內(nèi)容鎖定是什么

“鎖定”在cache中的塊在常規(guī)的cache替換操作中不會(huì)被替換，但當(dāng)通過(guò)C7控制cache中特定的塊時(shí)，比如使某特定的塊無(wú)效時(shí)，這些被“鎖定”在cache中的塊也將受到相應(yīng)

2023-10-31 11:31:21

315

Cache寫(xiě)入方式原理簡(jiǎn)介

提高高速緩存命中率的最好方法是盡量使Cache存放CPU最近一直在使用的指令與數(shù)據(jù)，當(dāng)Cache裝滿后，可將相對(duì)長(zhǎng)期不用的數(shù)據(jù)刪除，提高Cache的使用效率。為保持Cache中數(shù)據(jù)與主存儲(chǔ)器中數(shù)據(jù)

2023-10-31 11:43:37

532

關(guān)于CXL的功能與特性詳解

CXL.io 和CXL.cache 是CXL 協(xié)定中的兩個(gè)子協(xié)定，它們的功能和用途有所不同，主要是為了引入非對(duì)稱的概念；CXL.io 類似于PCIe 的事件（event），主要用于初始化、鏈接、設(shè)備發(fā)現(xiàn)、列舉以及寄存器(register) 的存取，從某種程度上說(shuō)，它可以看作是PCIe事件的一個(gè)變種。

2023-11-22 15:43:58

464

什么是CXL技術(shù)？CXL的三種模式、類型、應(yīng)用

2024-01-11 16:53:38

413

已全部加載完成

搜索歷史

一文詳解CXL.cache協(xié)議

評(píng)論