[編號ODCC-2025-03002]ETH-XScaleUp互聯(lián)協(xié)議白皮書V1.0開放數(shù)據(jù)中心標準推進委員會ODCC2025年9月版權(quán)聲明作權(quán)法》保護，編制單位共同享有著作權(quán)。轉(zhuǎn)載、摘編或利用其它方式使用ODCC成果中的文字銷售、改編、匯編和翻譯出版等侵權(quán)行為，ODCC及有關(guān)單位將追究其法律責任，感謝各單位的配合與支持。 3 3 4 7 29 AppendixA：AnnexCAQMO 圖1GPU互聯(lián)拓撲與當前技術(shù)形態(tài) 4 圖2ETH-X超級GPU 4 圖3直接互聯(lián)拓撲 5 圖4交換機Radix數(shù)量與拓撲規(guī)模的關(guān)系 5 圖5單層交換機的FatTree拓撲 6 圖6交換機背靠背的FatTree拓撲 6 圖7多層交換機的Clos拓撲 6 圖8計算通信kernel分離模式 7 圖9計算通信融合kernel實現(xiàn)模式 8 圖10DirectCopy示意圖 9 圖11DirectAccess示意圖 圖12UVA機制示意圖 圖13ScaleUp需求概覽 圖14ScaleUpIO直接支持總線事務(wù)傳輸 圖15基于Ethernet技術(shù)的不可靠域 圖16多級負載均衡示意圖 圖17Little’sLaw計算OutstandingBuffer容量 圖18負載均衡破壞程序順序示例 圖19AXI通道模型 圖20線程間數(shù)據(jù)同步場景 圖21觀察順序?qū)е聰?shù)據(jù)錯誤的例子 圖22事務(wù)經(jīng)過ScaleUp傳輸導致數(shù)據(jù)錯誤的例子 圖23事務(wù)經(jīng)過端側(cè)IOD上亂序處理導致數(shù)據(jù)錯誤的例子 24 圖24IOD間正確處理Release語義的例子 圖25IOD間負載均衡破壞Release語義的例子 圖26不支持全局一致性導致破壞Release語義的例子 圖27一種源端實現(xiàn)全局一致性的方式 圖28拷貝引擎對比 圖29一種網(wǎng)絡(luò)融合的方式 圖31ETH-X協(xié)議棧概覽 圖32直接訪問語義，直接拷貝語義 圖33IO模塊能力概覽 圖34PAXI整體架構(gòu)圖 圖35PAXI發(fā)送端事務(wù)層處理流程 圖36PAXI接收端事務(wù)層處理流程 圖37仲裁和拼裝TLflit流程圖 49 圖38組裝MACPacket流程圖 49 圖39TLFlit格式 圖40AXITLFlit包格式 53 圖41APBTLFlit格式 圖42MAC包組包規(guī)則 圖43利用Credit控制訪問請求的流程圖 圖44利用Credit控制訪問響應(yīng)的流程圖 圖45頭壓縮收益量化示意圖（來源：UEC） 圖46ETH-XPRI幀格式 圖47ETH-XVLAN+PRI幀格式 圖48擴展頭部格式 圖49UECLLR機制的系統(tǒng)位置 圖50LLR與MAC層交互方式示意圖 圖51CBFC工作流程圖 圖52CBFC模塊示意圖 圖53CBFCCC_Update控數(shù)據(jù)包格式 圖54CBFC信令更新流程 80 圖55PFC流控示意圖 83圖56標準以太和LLR-eligible以太前導示意圖 錯誤！未定義書簽。 圖57ControlOrderedSets擴展 87 圖58基于IO芯粒的互聯(lián)示意圖 88 圖59Die-to-Die協(xié)議概覽 89 圖60Die-to-Die物理封裝方式 90 圖61UCIe互聯(lián)協(xié)議 90表1AXI能力特性 表2寫請求通道 40表3寫數(shù)據(jù)通道 42表4寫響應(yīng)通道 43表5讀請求通道 43表6讀數(shù)據(jù)通道 45表7APB通道 46表8DAMappingRegisterX_0 48表9MappingRegisterX_1 48表10寄存器RemoteAPBCTRL 表11寄存器RemoteAPBDATA 51表12寄存器RemoteAPBRDATA 表13寄存器MessageCtrl 表14Sub-Flit中各通道標識和長度 表15APBTLFlit字段格式 表16數(shù)據(jù)通道的信令寄存器（DA0~127） 表17信令寄存器各字段含義 表18核心機制示意 表19LLR數(shù)據(jù)幀前導碼的MII格式 表20LLR數(shù)據(jù)幀前導碼的64/66b編碼 表21LLR控制塊類型和定義 68表22LLR控制塊的64/66b編碼 表23CBFC關(guān)鍵配置項 表24CBFC關(guān)鍵狀態(tài)變量 表25CBFC控制消息 表26CBFCCF_Update控制塊xMII格式 表27CBFCCF_Update控制塊字段和定義 表28CBFCCC_Update數(shù)據(jù)包字段和定義 85表30100Gbps/L系列 85表3150Gbps/L系列（含ETC規(guī)格） 861一、范圍二、術(shù)語和縮略語2存訪問技術(shù)，通過在以太網(wǎng)基礎(chǔ)上實現(xiàn)高效的RDMA通信，提高網(wǎng)DLB，DynamicLoadBalancing：動態(tài)負載分擔，通過引入時間Credit：信用。允許發(fā)送方傳輸數(shù)據(jù)包，并在發(fā)送方傳輸數(shù)據(jù)包3三、ScaleUp互聯(lián)需求452.Switch互聯(lián)拓撲通過交換機可使GPU的互聯(lián)帶寬具有帶寬池化能力，任意流量模式67（三）應(yīng)用場景與語義需求1.計算通信Overlap的實現(xiàn)方式8并行計算任務(wù)中的計算和通信部分融合成一個Kernel的實現(xiàn)是92.DirectCopy：先拷貝，后使用3.DirectAccess：邊讀寫，邊使用直接訪存（DirectAccess）允許計算引擎從遠端HBM存儲中直4.統(tǒng)一編址能力（UnifiedVirtualAddress）型，開發(fā)者可以像操作單個大容量顯存一樣使用多GPU系統(tǒng)，而不1.ScaleUpIO模塊的能力需求，ScaleUpIO模實際上該模塊不一定以芯粒形式加入系統(tǒng)，也可以作為XPU2.面向應(yīng)用的內(nèi)存模型需求，應(yīng)用層的編程接口和語義支持不同的XPU設(shè)計，對AXI接口上內(nèi)存保序的能力不同。需要（五）IOD模塊基礎(chǔ)功能需求1.AXIAdapter接口會被轉(zhuǎn)化成AXI總線事務(wù)進行傳輸和處理，ScaleUpIO模塊會直接接入AXI總線并負責將跨卡AXI訪存事務(wù)轉(zhuǎn)發(fā)至目的地。ScaleUpIO并且完成事務(wù)的調(diào)度、路由、聚合、解析等功能，在目的端正確、按2.聚合引擎與Eth頭部壓縮有效傳輸效率可以提升至：128/(16+16+128+6+6)=74%?？紤]最小3.系統(tǒng)級可靠性需求GPU核心在發(fā)起訪存事務(wù)時在端側(cè)維護一組事務(wù)隊列，事務(wù)元4.傳輸層流控5.多級負載均衡GPU內(nèi)存訪問事務(wù)在傳輸時會經(jīng)過多級互聯(lián)實體，事務(wù)在每一應(yīng)側(cè)完成，而Push類型事務(wù)允許由中間代理節(jié)點代為響應(yīng)，只需代ScaleUp互聯(lián)系統(tǒng)在應(yīng)用層面，其編程接口和語義設(shè)計對內(nèi)存事1.單指令流的局部保序GPUCore作為計算的核心單元，其對內(nèi)存事務(wù)的排序有著固有相互獨立，在傳輸和處理過程中不存在順序約束，經(jīng)過AXI總線的為使經(jīng)過AXI通道傳輸?shù)氖聞?wù)依然滿足GPU期望的相同指2.釋放一致性內(nèi)存模型對于不同線程之間的內(nèi)存訪問請求，GPUC操作（如acquire和release）的前提下，對不同地址的讀寫操作進行回（WriteBack）到一致性根。這不僅僅是刷新目標地址對應(yīng)的緩存生產(chǎn)者GPU完成數(shù)據(jù)寫入后，會通過寫入一個標志（Flag）來通知真正準備好之前就讀取到Flag，并開始訪問不完整或Synchronize-with關(guān)系。硬件需要確保執(zhí)行時不會出現(xiàn)違背程序員意不同IOD以及其對應(yīng)的網(wǎng)絡(luò)平面處理事務(wù)而IOD平面間不存在控制交互，可能導致某組IOD平面的Release3.全局釋放一致性內(nèi)存模型和通信圖中下一個GPU進行。然而，當系統(tǒng)中的通信模型涉及多個要系統(tǒng)滿足訪存事務(wù)的全局一致性才可保證（八）專用的ScaleUp拷貝引擎拷貝引擎實現(xiàn)DirectCopy語義會引入更多實現(xiàn)復雜性和資源開銷。4）DirectCopy語義統(tǒng)效率。此內(nèi)存屏障會到GPU域內(nèi)大范圍消息阻塞，從而降輸優(yōu)化，專用拷貝引擎應(yīng)支持GPU控制直接發(fā)起傳輸和直接通知（九）未來需求探討：ScaleUp和ScaleOut融合上都有明顯的交錯運行特征，GPU通常不會同時在兩張網(wǎng)絡(luò)上達到然而，必須意識到兩張網(wǎng)絡(luò)融合依然有許多待解決的挑戰(zhàn)，（十）未來需求探討：GNAI統(tǒng)一編程接口 四、ETH-X協(xié)議?？傮w概覽（二）ETH-X軟硬件交互界面GPU的顯存，通常是以Load/Store指令的方式進行，這種技術(shù)的優(yōu)（三）ETH-X事務(wù)層：GPU-GPU訪存協(xié)議以承載于ETH-X數(shù)據(jù)鏈路層之上。ETH-X建議GPU（四）ETH-X數(shù)據(jù)鏈路層：GPU-Switch互通協(xié)議足數(shù)據(jù)在網(wǎng)絡(luò)中正確傳輸、轉(zhuǎn)發(fā)和流控。ETH-X建議利用現(xiàn)有的交物理層遵循IEEE802.3標準，支持單通道50Gb/s，100Gb/s和太KP4FEC前向糾錯和CRC冗余校驗保護數(shù)據(jù)完整性FEC碼塊根（六）Die-to-Die互聯(lián)：IO芯片與計算芯片的交互界面五、事務(wù)層：GPU-GPU訪存協(xié)議議規(guī)定的5個通道。CAXI和DAXI接口除信號位寬可能不同外，無（二）AXI訪存協(xié)議AXI（AdvancedeXtensibleInterface）作為AMBA標準的一部的并行處理，主設(shè)備無需等待當前事務(wù)完成即可發(fā)起新請求，減（三）PAXI（Peer-to-PeerAXI）特性概覽以太網(wǎng)控制器配合提供C2C互聯(lián)，可對接單層或多接口1.發(fā)送端工作流程道下的User信號。該信號按一定映射規(guī)則會對應(yīng)確定的DA則打包成一個flit包。每個周期DAXI接口和CAXI接口都分在相應(yīng)的AXI通道中，等待PAXI打包，AXI相應(yīng)通道的的MAC包，若可以，則合并到MAC包中，否則發(fā)送現(xiàn)有（6）MAC包在完成組裝后發(fā)送至MAC層，組成MAC幀后經(jīng)2.接收端工作流程（五）PAXI對上層接口的信號列表1.寫請求信道（WriteRequestChannel）114832143142N1511D111translatedindicato24基于頁面的硬件屬性（based4D61H2內(nèi)存加密上下文標識符（MemoryEncryptionContextide2.寫數(shù)據(jù)信道（WriteDataChannel）111WUSER13.寫響應(yīng)信道（WriteResponseChannel）111112USER_RESP_124.讀請求信道（ReadReques11讀通道事務(wù)標識符（Transaction4832ARLOCK14314ARUSER21D1V11W24基于頁面的硬件屬性（based4D請求攜帶的MPAM信息（MPAM112EncryptionContextide5.讀數(shù)據(jù)信道（ReadDataChannel）111/11126.APBChannels1131111?寫傳輸時有效，讀傳輸必須無效111HH2.網(wǎng)絡(luò)地址寄存器address[31:0].eChanneluserbitmapedtoDesaddress[47:32].3.初始化配置注冊網(wǎng)絡(luò)地址寄存器注冊配置需要在同一通信域內(nèi)的GPU協(xié)商后共（七）TLFlit與PAXIMACPacket封裝方式1.事務(wù)層TLFlit打包規(guī)則DA下所有通道的信息（信息指相應(yīng)通道的所有接口的數(shù)據(jù)）打包成一個事務(wù)層TLflit，因此相同DA下不同事務(wù)APB的事務(wù)并非是直接將APB接口的信號打包成APBTLFlit,0WRRemoteDA,HighbitsWRACK 102.TLFlit封裝格式 來指示當前Flit包含AXI接口哪些通道的事務(wù)，PNoteSumofallthedataWchannelsignalswidthSumofallthedataRchannelsignalswidthSumofallthedataAWchannelsignalswidthSumofallthedataARchannelsignalswidthSumofallthedataBchannelsignalswidthNOPpaddingWR3.TLflit仲裁組裝MACPacket方式4.TLflit打包為MACPacket規(guī)則（2）若現(xiàn)有TLFlit和現(xiàn)有的MAC包DA不同，則將現(xiàn)有是直接發(fā)送至MAC層1.Credit動態(tài)更新2.Credit控制發(fā)送流程事務(wù)請求的發(fā)送流程如下。事務(wù)響應(yīng)的發(fā)送流程如下。3.Credit配置寄存器PAXITXstalltransferwheWRSetAW/WchannelmaxcreditthresholPAXITXstalltransferwhe（九）PAXI事務(wù)順序六、數(shù)據(jù)鏈路層：GPU-Switch互通協(xié)議（一）轉(zhuǎn)發(fā)效率優(yōu)化：ETH-XPRI幀格式1.ETH-XPRI幀格式設(shè)計考量2.ETH-XPRI幀格式圖46ETH-XPRI幀格式絡(luò)地址用于網(wǎng)絡(luò)路由字段。其余10字節(jié)為設(shè)備地址DefinedAddress）用于設(shè)備內(nèi)部尋字段位置、長度及掩碼由GPU上層實現(xiàn)指定（不同GPU實式，同時支持隔離和開銷壓縮，以支持更加靈活的高帶寬域計算方式實現(xiàn)報文壓縮和安全隔離/多租雙重能力，以提供給系統(tǒng)解決方 3.擴展設(shè)計（二）可靠性增強：L2LLR（鏈路層重傳機制）機制，當鏈路的一端探測到FEC錯誤時，可以快1.鏈路層重傳機制的設(shè)計考量本章節(jié)涉及到LLR鏈路層重傳機制主要考量：2.鏈路層重傳系統(tǒng)概覽確保了從MAC層收到的符合LLR的每一個幀都經(jīng)過正確性確認和如果接收到的報文的SN跟預期的不一致，也會發(fā)送NACK。ACK發(fā)送端收到ACK后，會從重傳緩沖區(qū)（ReplayBuffer）里面刪表18核心機制示意（4）LLR機制與MAC控制層的交互 3.LLR數(shù)據(jù)幀的前導碼格式e123e5ee 0467B555B]555Sync2k7ble55e>>554.LLR控制塊格式LLR機制使用特殊的控制塊向鏈路對端發(fā)送控制消息。PCS會 指示已接收到并處理了LLR_INIT控制塊，并已準備好接收LLR_INIT和LLR_INIT_ECHO類型的初始化數(shù)據(jù)位分別位于c276000K60006060（三）流控能力增強：CBFC在無損結(jié)構(gòu)中，數(shù)據(jù)包的逐跳傳播通過適當?shù)逆溌芳壛髁靠刂品桨笇崿F(xiàn)無損。在鏈路層，可以通過利用鏈路級流量控制使得僅在接收方有可用緩沖區(qū)空間時才允許數(shù)據(jù)包傳輸，從而控制鏈路之間的無損從而實現(xiàn)無損以太網(wǎng)結(jié)構(gòu)。無損結(jié)構(gòu)在小規(guī)模上易于管理，并且不會CBFC（CreditBasedFlowControl）是一種鏈路層的基于信用的對于無損傳輸，需要在接收側(cè)預留相應(yīng)的保留緩沖區(qū)（Headroom1.CBFC和PFC的相對優(yōu)勢如果低估了電纜延遲，PFC可能會出現(xiàn)緩沖區(qū)溢出和丟包，但使用XOFF-XON流量控制比基于信用的流量控制實現(xiàn)PFC可以實現(xiàn)跨端口共享突發(fā)緩沖區(qū)，從而有效利用緩沖區(qū)資當沒有流控制事件發(fā)生時，PFC可充分利用鏈路帶寬（無消息2.CBFC功能列表PFC可用于管理另一個資源，例如第二個緩沖點和/或另一個每3.CBFC流控能力概覽發(fā)送方和接收方都會在循環(huán)計數(shù)器中跟蹤已消耗的信用和已釋放的信用，這些計數(shù)器會在鏈路伙伴之間定期同步。通過不斷增加計用限額(CL)來限制發(fā)送到接收方的無損VC上的數(shù)據(jù)包數(shù)量，使 4.CBFC關(guān)鍵變量NumVCs]11送方傳輸數(shù)據(jù)包所使用的信用數(shù)量而增NumVCs]NumVCs]NumVCsNumVCs當發(fā)送方從鏈路對端收到信令控制消息]NumVCs當接收端從鏈路對端收到信令控制消息]NumVCs當接收方緩沖區(qū)可用于接收更多數(shù)據(jù)包CF和CC計數(shù)器的大小取決于更新消息的頻率以及鏈路之間的往返時間(RTT)和接收器專用輸入緩沖區(qū)的大 CC計數(shù)器可以在更新之間支持高達32MB的緩沖區(qū)大小。要使5.CBFC控制消息CC_Update–從發(fā)送方到接收方的CC計的是更新由于鏈路錯誤（例如不可糾正的FEC錯誤或數(shù)據(jù)包CRC接收端向發(fā)e發(fā)送端向接CC_Update的主要目的是恢復由于鏈路錯誤導致的數(shù)據(jù)包丟失而泄如果由于鏈路錯誤而丟棄數(shù)據(jù)包，則發(fā)送方的S_VC_CC[x]計CC_Update消息是發(fā)送方通知接收方其認為已消耗的信用額度CC_Update數(shù)據(jù)包包含最多16個發(fā)送方的S_V器值，這些值包含在64字節(jié)以太網(wǎng)數(shù)據(jù)包中。CC_Update數(shù)據(jù)包包所消耗的所有信用，并且絕不能包括在CC_Update數(shù)據(jù)包之后傳Forx=0to(NumVCs-1)LostCredits=S_VC_CC[x]–R_VC_CC[x]If(LostCredits>0)thenR_VC_CF[x]=R_VC_CF[x]+LostCreditsR_VC_CC[x]=S_VC_CC[x]endforCF_Update消息包含從接收方到發(fā)送方的R_VC_CF[x]值。它CF_MAX_TIMER用于定期更新所有R_VC_CFcredits_returned=R_VC_CF[x]–S_VC_CF[x]S_P_CU=S_P_CU–credits_returnedS_VC_CU[x]=S_VC_CU[x]–credits_returnedS_VC_CF[x]=R_VC_CF[x]6.CBFC消息格式0123567 54540048323640444860MACDAMACSAEth-Type(0x8808)Opcode(0xFFFE)OUIMsgTypeS_VC_CC[i]S_VC_CC[i+15]字段長16個CC計數(shù)器值，每個計數(shù)器值長度為或7.數(shù)據(jù)包和信令處理流程pktSize=sizeoftheEthernetframeinbytespktCredits=roundup((pktSize+PktOvhd)÷CreditSize)S_VC_CU[x]+pktCredits≤S_VC_CL[x]S_P_CU+pktCredits≤S_P_CL盡力而為的VC數(shù)據(jù)包傳輸不需要此信用檢查，也不會消耗信S_P_CU=S_P_CU+pktCreditsS_VC_CC[x]=S_VC_CC[x]+pktCreditsS_VC_CU[x]=S_VC_CU[x]+pktCreditspktSize=sizeoftheEthernetframeinbytespktCredits=roundup((pktSize+PktOvhd)÷CreditSize)R_VC_CC[x]=R_VC_CC[x]+pktCreditspktSize=sizeoftheEthernetframeinbytespktCredits=roundup((