做過多 die 芯片的人應(yīng)該都有同感scale-up 互連最折磨人的從來不是帶寬是緩存一致性。PCIe 時代聊互連談 lane 速率和 retimer到了 chiplet 和多 die 時代大家手里的尺子換成了協(xié)議——CHI 的七態(tài)狀態(tài)機怎么編碼TileLink 的 Acquire/Release 握手怎么設(shè)計UCIe 的鏈路層重傳狀態(tài)機兜不兜得住甚至路由策略都要站在協(xié)議狀態(tài)機的肩膀上重新思考。這篇文章就干一件事把 scale-up 互連里六個開放/開源協(xié)議的協(xié)議級細(xì)節(jié)掰開揉碎從 CHI 的七個緩存狀態(tài)到 PBR 路由策略在互連網(wǎng)絡(luò)里的落地方式再到狀態(tài)機的工程實現(xiàn)做一個比特和狀態(tài)機層面的全解剖。不管你是做 SoC 架構(gòu)、NoC 設(shè)計還是研究擴展內(nèi)存和加速器互聯(lián)這篇應(yīng)該都能給你一張可以直接拿去用的對照圖。1. Scale-up 互連到底在解什么題1.1 同樣叫互連Scale-up 和 Scale-out 是兩種物種很多做軟件的人一聽到 scale-up第一反應(yīng)是升級單機配置scale-out 才是加機器。但在芯片互連領(lǐng)域這兩個詞的差別比很多人想象中大得多。Scale-out 互連解決的是多臺獨立系統(tǒng)怎么高效通信的問題節(jié)點之間沒有共享內(nèi)存、沒有一致性問題以太網(wǎng)、RoCE、PCIe 都算這一類而 Scale-up 互連解決的是把多個計算 die、多個芯片拼成一個邏輯上的單機的問題拼完之后操作系統(tǒng)看到的是一整塊統(tǒng)一內(nèi)存CPU 訪問任意地址都該拿到正確的最新數(shù)據(jù)。這就帶來一個非常硬核的附加條件緩存一致性。Scale-out 里一臺機器改了數(shù)據(jù)另一臺機器由上層軟件用鎖、消息、分布式協(xié)議去同步但在 Scale-up 里如果 die 0 的 L2 緩存里有一個臟行die 3 的核去讀同一個地址互連協(xié)議必須保證它拿到的是 die 0 那份最新的值而不是內(nèi)存里的舊值。這個保證是由硬件協(xié)議在納秒級完成的軟件完全不感知。所以 scale-up 互連的核心不是高帶寬低時延這些物理指標(biāo)而是協(xié)議層的一致性狀態(tài)機、事務(wù)流和路由策略。這也是為什么業(yè)內(nèi)討論 scale-up 互連時談的幾乎都是協(xié)議。1.2 一致性協(xié)議是冰山下面的那部分看一個 scale-up 互連系統(tǒng)物理層、鏈路層、事務(wù)層、一致性層一層層摞上去最容易被低估的是最上面的一致性層。PCIe 的 TLP 告訴你一個包怎么可靠地從 A 到 B但 CNICoherent NoC Interconnect這一類協(xié)議還額外回答了幾個問題這個緩存行在哪個節(jié)點、處于什么狀態(tài)、誰有義務(wù)向別人提供數(shù)據(jù)、數(shù)據(jù)在什么條件下必須寫回內(nèi)存。這些問題全部落到狀態(tài)機里。比如一個最簡單的場景CPU 發(fā)起一個 ReadShared請求經(jīng)過互連網(wǎng)絡(luò)到 Home NodeHome Node 發(fā)現(xiàn)這個行的 Owner 在另一個 die于是發(fā)出 snoop/forward 給 OwnerOwner 把自己的緩存狀態(tài)從 dirty 降級并發(fā)數(shù)據(jù)回來Home Node 匯總之后再響應(yīng)給請求者。這中間涉及至少兩個節(jié)點的狀態(tài)跳變、三到四類通道的事務(wù)仲裁、以及必須保證的死鎖自由。協(xié)議設(shè)計稍有漏洞系統(tǒng)就可能出現(xiàn)死鎖、活鎖或者靜默的數(shù)據(jù)錯誤。做互連協(xié)議的人常開玩笑說物理層錯了頂多丟包重傳一致性層錯了就是最恐怖的那種 bug跑一百個小時才隨機掛一次掛之前沒有任何告警。1.3 六個協(xié)議的入選邏輯標(biāo)題里說六個開源協(xié)議我選的是 ACE、CHI、TileLink-C、CXL.cache、CCIX、UCIe。先解釋一下開源這個詞。嚴(yán)格的 open source 指的是 RTL 代碼開源只有 TileLink 做到了這一點——Rocket Chip 和 BOOM 里就是它的完整實現(xiàn)CHI 和 ACE 的協(xié)議文檔是 ARM 公開提供下載的也有開源社區(qū)實現(xiàn)和大量學(xué)術(shù)論文參考但 ARM 本身不開源 RTLCXL、CCIX、UCIe 屬于開放標(biāo)準(zhǔn)聯(lián)盟規(guī)范公開或?qū)Τ蓡T公開但實現(xiàn)各有版權(quán)。所以這六個里面有的是真開源有的是規(guī)范開放 參考實現(xiàn)可見我在后面每一節(jié)都會把授權(quán)狀態(tài)說清楚方便你自己判斷能不能直接抄作業(yè)。選這六個還有一層考慮它們正好覆蓋了 scale-up 互連的三個層面。ACE 和 CHI 是 CPU 側(cè)緩存一致性的演進路線CXL.cache 和 CCIX 解決的是加速器和內(nèi)存擴展設(shè)備如何參與一致性UCIe 則是 chiplet 時代把上面所有協(xié)議搬運到 die-to-die 鏈路上的底座。理解這一整個譜系你會比只盯著某一個協(xié)議的人對scale-up 互連有更立體的認(rèn)知。2. CHI 七態(tài)狀態(tài)機從 MESI 到七態(tài)的演化邏輯2.1 七個狀態(tài)逐一定義CHI 是 AMBA 5 里的 Coherent Hub Interface全稱叫 Coherent Hub InterfaceARM 用它替代總線式的 ACE面向點對點和 NoC/Mesh 拓?fù)?。CHI 最常被拿來當(dāng)談資的就是它的緩存狀態(tài)不是 MESI 的四態(tài)也不是 MOESI 的五態(tài)而是七個I、UC、UCE、UD、SC、SD、UDP。逐個拆開說。I 是 Invalid不解釋。UC 是 Unique Clean系統(tǒng)里只有這一份副本內(nèi)容干凈和內(nèi)存一致。UCE 是 Unique Clean Empty關(guān)鍵在 Empty這個行被分配了權(quán)限是唯一且干凈但數(shù)據(jù)根本沒搬過來。UD 是 Unique Dirty系統(tǒng)里唯一副本內(nèi)容是臟的比內(nèi)存新將來必須寫回。SC 是 Shared Clean多份共享內(nèi)容干凈。SD 是 Shared Dirty多份共享但其中這份是臟的它承擔(dān) Owner 角色別人要讀數(shù)據(jù)得找它要。UDP 是 Unique Dirty Partial唯一且臟但只有部分字節(jié)有效另外一部分字節(jié)是無效的。為什么 CHI 比 MOESI 多兩個因為傳統(tǒng) MOESI 處理不了我有一份數(shù)據(jù)但數(shù)據(jù)不全和我占了一個行但根本沒取過數(shù)這兩種工程上非常常見的情況。前者是 DMA 部分寫、字節(jié)使能寫這一類事務(wù)的產(chǎn)物后者是 full-line write 的產(chǎn)物。CHI 干脆把這兩個特殊場景顯性化成獨立狀態(tài)協(xié)議層面的行為立刻清晰了。2.2 三比特編碼與狀態(tài)位設(shè)計七個狀態(tài)放到底層最少三比特就能編碼。實際工程里常用的是特征位組合不是枚舉因為特征位方便做邏輯化簡。我見過一種很典型的編碼Valid、Unique、Dirty、DataValid 四個特征位再加一個 Partial 標(biāo)志。狀態(tài)ValidUniqueDirtyDataValid含義I0---無效SC1001共享干凈UC1101唯一干凈UCE1100唯一干凈但空UD1111唯一臟SD1011共享臟OwnerUDP1110唯一臟但部分字節(jié)有效部分有效在物理上怎么表達(dá)UDP 狀態(tài)必須配套一個 byte mask至少每 16 字節(jié)一個有效位。這個 mask 會跟著事務(wù)走Home Node 要根據(jù)它判斷請求者要的那一段字節(jié)到底該從 Owner 拿還是從內(nèi)存拿。這個細(xì)節(jié)在驗證階段是重災(zāi)區(qū)因為 UDP 的 hit 和 miss 行為差別很大隨機激勵很容易踩到部分字節(jié)沒有正確合并的 bug。三比特編碼有個好處是狀態(tài)寄存器的面積和功耗最小但也有工程團隊故意用四比特甚至五比特的特征位編碼理由是組合邏輯的 timing 更好收斂。我在實際項目中兩種都見過結(jié)論是狀態(tài)機本身用枚舉類型保證可讀性存到 SRAM/meta array 里之前再轉(zhuǎn)換成緊實的特征位兩頭的好處都占。2.3 典型事務(wù)的狀態(tài)流轉(zhuǎn)看幾條核心轉(zhuǎn)換路徑你就明白這七個狀態(tài)是怎么協(xié)作的。第一條是讀缺失。RN 發(fā) ReadShared 給 Home Node沒有其他副本時直接分配一個 SC數(shù)據(jù)從內(nèi)存返回。如果已經(jīng)有 Owner 持有一個 SDHome Node 就要向 Owner 發(fā) forwardOwner 把數(shù)據(jù)轉(zhuǎn)發(fā)給請求者自己從 SD 降級到 SC內(nèi)存不需要更新因為兩個緩存都持有這份數(shù)據(jù)了。這條鏈路的精妙之處在于內(nèi)存從頭到尾沒有被寫但請求者拿到了最新值這就是臟共享省帶寬的經(jīng)典操作。第二條是唯一寫。RN 發(fā) ReadUnique若發(fā)現(xiàn)別處有 SC 副本所有 SC 都要被 invalidate請求者拿到唯一權(quán)限。如果原先是 UD數(shù)據(jù)直接在緩存里改如果原先是 UC改成 UD 就行如果原先是 UCE那還要先把數(shù)據(jù)取回來。這條路徑對應(yīng)的是獨占寫的語義性能好不好就看 invalidate 的廣播效率。第三條是寫回。UD 行被替換或顯式 clean發(fā) WriteBack 給 Home NodeHome Node 負(fù)責(zé)把臟數(shù)據(jù)寫進內(nèi)存狀態(tài)清成 I。CHI 對 WriteBack 有 clean 和 data 兩種選擇工程上常用干凈寫回只通知不搬數(shù)內(nèi)存是否真的更新由內(nèi)存控制器自己決定這能省掉不少數(shù)據(jù)通道帶寬。2.4 UCE 和 UDP 這兩個特殊狀態(tài)的價值與坑UCE 是個很聰明的優(yōu)化。Full-line write 時CPU 要寫滿整個緩存行的所有字節(jié)數(shù)據(jù)根本沒必要先讀上來。協(xié)議允許直接分配一個 UCE 行寫操作把數(shù)據(jù)填進去狀態(tài)變成 UD。這樣一次完整的寫缺失省掉了一次內(nèi)存讀latency 和帶寬雙豐收。但坑也在這UCE 的數(shù)據(jù)是無效的如果后續(xù)來一個部分寫或者讀操作控制器必須先從別處取數(shù)。很多第一次寫 CHI 控制器的人把 UCE 當(dāng) UC 用直接返回數(shù)據(jù)結(jié)果整個系統(tǒng)的數(shù)據(jù)都是錯的。UDP 的招數(shù)更細(xì)。它服務(wù)的是部分寫命中場景已經(jīng)有唯一臟的數(shù)據(jù)但新寫的字節(jié)只占一部分。如果直接按整行臟處理之前那部分沒被覆蓋的舊數(shù)據(jù)是垃圾將來寫回內(nèi)存會把垃圾也寫進去。UDP 通過 byte mask 精確標(biāo)注哪些字節(jié)有效需要時把有效部分和內(nèi)存里讀出來的部分做 merge。理解了這個機制你再去讀 CHI 里那些帶著 mask 的 data 事務(wù)會順暢很多。3. PBR 路由在互連網(wǎng)絡(luò)里談策略路由3.1 網(wǎng)絡(luò)世界的 PBR 和互連世界的 PBRPBR 這個詞最早來自網(wǎng)絡(luò)Policy-Based Routing策略路由。普通路由是看目的 IP 查最長前綴PBR 則允許管理員說從這臺設(shè)備過來的流量走這條鏈、視頻流量走那條鏈、低優(yōu)先級流量繞過核心。說白了路由決定不再只依賴目的地址還疊加了源、協(xié)議類型、應(yīng)用的維度。到了 scale-up 互連里PBR 的邏輯完全復(fù)刻只是載體從 IP 包變成了一致性事務(wù)。NoC 上傳輸?shù)拿恳粋€ REQ、RSP、DAT flit往哪個 Home Node 走、走哪條物理路徑、占哪個虛擬通道、在仲裁器里拿什么優(yōu)先級這些都受到策略的支配而不只是查一下目的節(jié)點 ID 那么簡單。協(xié)議層的一致性要求給了路由策略一大堆新的約束這讓互連里的 PBR 比網(wǎng)絡(luò)里的 PBR 復(fù)雜得多。3.2 系統(tǒng)地址映射決定每一個請求去哪scale-up 互連的路由第一步是把物理地址映射到 Home Node。系統(tǒng)地址映射System Address Map是這里面的核心數(shù)據(jù)結(jié)構(gòu)它決定地址空間怎么切、切多大、以什么方式散落到多個 Home Node 上。最常見的做法是交織interleave。物理地址按固定粒度切塊比如 256 字節(jié)、4KB然后輪流分配給各個 Home Node。交織粒度選多大本質(zhì)就是一個策略問題粒度太小訪問模式能被充分地打散到各個節(jié)點內(nèi)存帶寬利用均衡但地址翻譯和跨節(jié)點局部性都會變差粒度太大某個節(jié)點可能成為熱點另一個節(jié)點閑得要死。工程上大塊交織配合哈希函數(shù)做二級映射是通用解法哈希能破壞順序訪問的規(guī)律性代價是難以保證訪存的物理局部性。從 PBR 的角度看這一步相當(dāng)于按地址前綴做路由是基礎(chǔ)策略。真正有意思的是在這一層之上加的額外規(guī)則比如某些保留地址段只允許特定節(jié)點訪問某些 DMA 窗口需要固定映射到特定 Home Node這類策略在做安全隔離和虛擬化時非常常見也是協(xié)議級路由和普通 NoC 路由最大的差別。3.3 協(xié)議級路由策略的三張牌第一張牌是事務(wù)類型。同一個請求目標(biāo)ReadShared 和 WriteNoSnp 的路徑可以完全不一樣。ReadShared 要經(jīng)過完整的 snoop/forward 流程對時延敏感應(yīng)該走低延遲通道WriteNoSnp 是一種不關(guān)心其他緩存、直寫內(nèi)存的事務(wù)它甚至可以發(fā)起后不等響應(yīng)走一個獨立的posted通道。把不同事務(wù)映射到不同虛擬通道是互連里最常見的策略路由實現(xiàn)。虛擬通道的好處是隔離REQ 通道被長事務(wù)堵住時RSP 通道還能繼續(xù)走這直接關(guān)系到協(xié)議不死鎖。第二張牌是 QoS。CHI 事務(wù)里帶 QoS 字段路由和仲裁都要參考它。實時核的事務(wù)比批處理核的優(yōu)先級高這個策略在運行時會動態(tài)影響 flit 的調(diào)度。但 QoS 策略必須小心優(yōu)先級不能反了。一個低優(yōu)先級事務(wù)占著一個互斥資源不放高優(yōu)先級事務(wù)在后面等就可能引發(fā)優(yōu)先級反轉(zhuǎn)在一致性協(xié)議里這是死鎖的溫床。第三張牌是節(jié)點親和性與距離感知。在 Mesh 拓?fù)淅飪蓚€ die 離得遠(yuǎn)就意味著更高的跳數(shù)和時延。有經(jīng)驗的系統(tǒng)會在系統(tǒng)地址映射階段就把經(jīng)?；ハ嗤ㄐ诺墓?jié)點盡量映射到相鄰的 Home Node 上。這個策略在運行時甚至可以做動靜結(jié)合運行初期按靜態(tài)表路由發(fā)現(xiàn)熱點后通過重映射指令遷移部分地址區(qū)域的服務(wù)節(jié)點。這部分實現(xiàn)起來很復(fù)雜多數(shù)商業(yè)芯片第一版是禁用的先把正確性搞定再優(yōu)化局部性。4. 六個開放協(xié)議橫向解剖4.1 ACE總線式一致性CHI 的前身ACE 是 AMBA 4 的 AXI Coherency Extensions在 AXI 的基礎(chǔ)上加了 snoop 通道和一致性響應(yīng)語義讓多個處理器還能掛在共享總線上。它的實現(xiàn)方式是總線監(jiān)聽所有對共享地址的訪問都廣播到總線上每個緩存控制器自己判斷要不要介入。這在一個小規(guī)模 cluster 里足夠用拓?fù)浜唵?、協(xié)議直白。但 ACE 的天花板很明顯廣播式監(jiān)聽的可擴展性差。核一多總線上到處都是 snoop 流量一致性帶寬被浪費在無效的探查上。所以 ARM 在 AMBA 5 里推出了 CHI把拓?fù)鋸目偩€改成點對點互連 Home Node 集中管理地址snoop 從廣播變成了按需定向轉(zhuǎn)發(fā)。ACE 不是沒有意義恰恰是 ACE 的實踐把總線一致性走到頭了這件事驗證得非常清楚CHI 的設(shè)計者才能放心地把總線模式丟掉。ACE 的授權(quán)狀況是規(guī)范公開下載有少量開源參考但現(xiàn)在新項目里已經(jīng)很少直接用 ACE 做多 die 擴展了。4.2 CHI面向 P2P 與 Mesh 的主流通用協(xié)議CHI 是目前數(shù)據(jù)密集型 SoC 里最主流的一致性協(xié)議大量服務(wù)器芯片都在用它規(guī)格也一直在演進。它的核心模型是三類節(jié)點RN 負(fù)責(zé)發(fā)起請求HN 負(fù)責(zé)做地址歸屬和一致性裁決SN 負(fù)責(zé)接內(nèi)存或外設(shè)。緩存行的時間戳、Owner 記錄、共享列表都由 HN 維護這讓它天然適合點對點和 NoC 拓?fù)?。CHI 的通道設(shè)計是 REQ/RSP/DAT 三類細(xì)分 TX 和 RX事務(wù)在三個通道上完成一次握手。這個模型對 NoC 非常友好因為三個通道可以各自獨立走不同路徑和虛擬通道。前面講的七態(tài)狀態(tài)機就是 CHI 對 RN 側(cè)緩存行為的規(guī)定。CHI 文檔有公開下載版本網(wǎng)上也能找到一些開源實現(xiàn)和教學(xué)用 RTL是六個協(xié)議里能讀到完整狀態(tài)機定義的一個。如果你做 scale-up 互連CHI 值得當(dāng)主參照系其他協(xié)議跟它對比著看會很容易抓住差異。4.3 TileLink-CRISC-V 生態(tài)的原生選擇TileLink 是 SiFive 搞的開放式互連協(xié)議在 RISC-V 生態(tài)里幾乎成了標(biāo)配?？偣灿?TileLink-UL、TileLink-UH、TileLink-C 三級其中 TileLink-C 是帶緩存一致性的一級。它的設(shè)計思路和 CHI 不太一樣TileLink-C 沒有直接定義一套七態(tài)而是通過 Acquire/Release/Probe 這三類原語來操作緩存行權(quán)限協(xié)議文檔里給的是 I/B/T 三個管理端狀態(tài)客戶端通常自行實現(xiàn) MESI 權(quán)限組合。這種設(shè)計很符合open的氣質(zhì)協(xié)議規(guī)定行為語義具體狀態(tài)編碼交給實現(xiàn)者去定。Rocket Chip 的 L2 管理器里你用兩三個比特就能把 I/B/T 存下來狀態(tài)機簡潔到可以看懂每一行。TileLink 是真正 RTL 開源的協(xié)議你可以在 GitHub 上找到全套實現(xiàn)這對做研究和教育來說價值極大。它的代價是生態(tài)相對封閉在 RISC-V 世界里想在 ARM 系或者混合體系里用它得自己處理協(xié)議適配。4.4 CXL.cache讓設(shè)備也擁有一致性視圖CXLCompute Express Link是當(dāng)前內(nèi)存擴展最熱的標(biāo)準(zhǔn)它由 CXL.io、CXL.cache、CXL.mem 三部分組成。CXL.cache 干的事是讓一個加速器設(shè)備能夠像 CPU 一樣擁有自己的緩存并且通過協(xié)議和主機保持一致性。設(shè)備側(cè)可以緩存主機內(nèi)存的某些行主機側(cè)有 snoop 過濾器跟蹤設(shè)備緩存了哪些行設(shè)備訪問命中時直接從設(shè)備緩存返回不用每次都穿 PCIe/CXL 鏈路回主機。CXL.cache 的緩存行狀態(tài)大概是 I/S/E/M/D 這一類D 表示臟數(shù)據(jù)設(shè)備在替換時需要把臟數(shù)據(jù)回寫。CXL 的協(xié)議棧整體是開放的模擬器層面有很多開源工作比如基于 QEMU 的 CXL 模擬器就能直接跑 CXL.cache 的流量。對芯片設(shè)計者來說CXL.cache 和 CHI 的一個重要差異是CXL.cache 的設(shè)備側(cè)是被動監(jiān)聽為主它信任主機的 snoop 過濾器這比 CPU 之間平等的 snoop 機制簡單了很多但代價是錯誤處理能力不如對等協(xié)議強。4.5 CCIX曾經(jīng)的開路先鋒CCIX 是最早一批想通過 PCIe 物理層實現(xiàn)加速器緩存一致性的開放標(biāo)準(zhǔn)之一2016 年前后很活躍。它的思路是改造 PCIe 事務(wù)層在 PCIe PHY 上疊加一致性語義讓加速器能和主機 CPU 在同一緩存一致性域里工作。這個概念在當(dāng)時非常前沿也間接推動了后來 CXL 的快速落地。但 CCIX 的宿命不太好。它和 CXL 在目標(biāo)市場上高度重疊而 CXL 生態(tài)推廣更猛、巨頭支持更多CCIX 聯(lián)盟后來基本停止運營項目并入 CXL 的體系。我在協(xié)議對比里仍然留了它的位置因為它的設(shè)計文檔對理解在已有 PHY 上疊加一致性語義這個思路非常有參考價值。它的緩存狀態(tài)模型屬于 MOESI 家族但你去看歷史實現(xiàn)會發(fā)現(xiàn)真正難的不是狀態(tài)定義而是把一致性握手塞進 PCIe 原有的包格式里CCIX 踩過的坑 CXL 今天還在避。4.6 UCIechiplet 時代的底座UCIeUniversal Chiplet Interconnect Express是 chiplet 互連的開放標(biāo)準(zhǔn)它解決了多 die 封裝里怎么把 die 連起來的問題。嚴(yán)格說UCIe 不是一致性協(xié)議它的協(xié)議棧是分層的物理層負(fù)責(zé) die-to-die 高速收發(fā)鏈路層負(fù)責(zé)可靠傳輸和重傳狀態(tài)機適配層負(fù)責(zé)把不同的上層協(xié)議PCIe、CXL、流式協(xié)議映射到統(tǒng)一的數(shù)據(jù)傳輸上。UCIe 的狀態(tài)機主要藏在鏈路層的訓(xùn)練和重傳流程里。鏈路訓(xùn)練狀態(tài)機跟 PCIe 的 LTSSM 有點像上電后要經(jīng)歷從復(fù)位、配置、校準(zhǔn)到 active 的跳變每個階段有超時和錯誤恢復(fù)重傳機制則依賴序列號和數(shù)據(jù)緩沖丟包時回退重傳。對 scale-up 互連來說UCIe 是承重墻一樣的底座上層跑 CHI 還是 CXL底層都會被轉(zhuǎn)換成 UCIe 的 flit 在先進封裝里傳輸。它的規(guī)范對成員開放但核心文本不是完全免費的好在大量公開資料和第三方實現(xiàn)足夠讓你把狀態(tài)機搞清楚。4.7 一張表看全六家差異協(xié)議維護方一致性角色定位拓?fù)浼僭O(shè)狀態(tài)機風(fēng)格開源程度ACEARMCPU 緩存一致性總線/共享介質(zhì)MESI 家族公開文檔參考實現(xiàn)少CHIARMCPU 緩存一致性點對點/NoC/Mesh七態(tài)公開文檔有開源實現(xiàn)TileLink-CSiFiveCPU 緩存一致性NoCI/B/T 管理端客戶端 MESI 類完全開源 RTLCXL.cacheCXL 聯(lián)盟設(shè)備緩存一致性點到點主機-設(shè)備I/S/E/M/D 類開放標(biāo)準(zhǔn)開源模擬器CCIXCCIX 聯(lián)盟已并入 CXL加速器一致性PCIe PHY 疊加MOESI 類公開文檔已停止運營UCIeUCIe 聯(lián)盟chiplet die-to-die 底座先進封裝/長走線鏈路訓(xùn)練與重傳狀態(tài)機成員開放第三方實現(xiàn)可見對比這張表能得出幾個結(jié)論。第一CPU 側(cè)一致性協(xié)議的演進主線是 ACE 到 CHI拓?fù)鋸目偩€走向網(wǎng)絡(luò)狀態(tài)從粗粒度走向細(xì)粒度。第二設(shè)備側(cè)協(xié)議 CXL.cache 和 CCIX 追求的是夠用的一致而不是對等的一致復(fù)雜度也因此低不少。第三TileLink 在開源生態(tài)里的地位不可替代它的實現(xiàn)能直接跑起來是學(xué)習(xí)一致性狀態(tài)機的最好入口。第四UCIe 作為底座決定上面這些協(xié)議最終以什么物理形態(tài)在 chiplet 系統(tǒng)里落地它的狀態(tài)機雖不是緩存狀態(tài)但對正確性同樣生死攸關(guān)。5. 狀態(tài)機的工程實現(xiàn)從三段式 Verilog 到 C 模型5.1 為什么三段式 Verilog 是標(biāo)準(zhǔn)答案很多剛從軟件轉(zhuǎn)過來寫狀態(tài)機的人第一版代碼往往是一段式一個 always 塊里既管狀態(tài)跳轉(zhuǎn)又管輸出寫起來確實快幾十行就搞定。但芯片設(shè)計中一旦狀態(tài)機復(fù)雜到幾十個狀態(tài)、十幾個輸入事件一段式的代碼就沒法看了。組合邏輯和時序邏輯混在一起仿真波形里你分不清某個信號變動是狀態(tài)跳變導(dǎo)致的還是輸出邏輯純組合產(chǎn)生的定位 bug 的時候非常痛苦。工業(yè)界的標(biāo)準(zhǔn)寫法是三段式狀態(tài)機。第一段只負(fù)責(zé)鎖存當(dāng)前狀態(tài)時序邏輯干凈利落第二段是純組合邏輯根據(jù)當(dāng)前狀態(tài)和輸入計算次態(tài)第三段再根據(jù)狀態(tài)或次態(tài)產(chǎn)生輸出。三段分隔之后狀態(tài)跳轉(zhuǎn)路徑和輸出邏輯互不干擾綜合工具也容易把組合邏輯優(yōu)化得更緊湊。我自己做協(xié)議控制器這么多年凡是能堅持三段式的項目后仿真階段的問題數(shù)量都明顯少于一段式。所謂標(biāo)準(zhǔn)答案不是教條是無數(shù)項目踩坑踩出來的經(jīng)驗。5.2 七態(tài)緩存狀態(tài)機的 Verilog 骨架以一個 CHI RN 側(cè)緩存行的狀態(tài)機為例三段式的骨架長這樣。第一個 always 塊鎖存狀態(tài)寄存器第二個 always 塊做組合邏輯的次態(tài)計算第三個 always 塊處理數(shù)據(jù)或標(biāo)志位的更新。注意次態(tài)計算里用了默認(rèn)保持自身的寫法避免產(chǎn)生 latch。// 第一段狀態(tài)寄存器 always (posedge clk or negedge rst_n) begin if (!rst_n) state_q I; else state_q state_d; end // 第二段次態(tài)組合邏輯 always (*) begin state_d state_q; case (state_q) I: begin if (req_valid req_op READ_SHARED) state_d SC; else if (req_valid req_op READ_UNIQUE) state_d UD; else if (req_valid req_op WRITE_FULL) state_d UD; end SC: begin if (probe_valid probe_op INVALIDATE) state_d I; else if (req_valid req_op READ_UNIQUE) state_d UD; end UCE: begin if (req_valid req_op WRITE_PARTIAL) state_d UD; else if (req_valid req_op READ_UNIQUE) state_d UD; end UD: begin if (evict_valid evict_op WRITEBACK) state_d I; end // 其余狀態(tài)分支略 default: state_d I; endcase end // 第三段數(shù)據(jù)通路和標(biāo)志位更新 always (posedge clk or negedge rst_n) begin if (!rst_n) data_valid_q 1b0; else if (state_q I state_d SC) data_valid_q 1b1; // 數(shù)據(jù)從 data channel 寫入 else if (state_q UD state_d I) data_valid_q 1b0; // 寫回完成行失效 end這段代碼只是教學(xué)骨架真實項目的輸入事件要多得多比如 snoop 響應(yīng)、error 響應(yīng)、QoS 變化都會影響狀態(tài)跳轉(zhuǎn)。但骨架的意義在于告訴你狀態(tài)跳轉(zhuǎn)、數(shù)據(jù)更新、輸出產(chǎn)生這三件事被物理分開了出了 bug 你可以順著三個 always 塊逐一排查。5.3 用 C 語言把協(xié)議狀態(tài)機跑起來芯片 tapeout 之前我們習(xí)慣用 C 模型把協(xié)議狀態(tài)機跑一遍幾百兆次隨機事務(wù)幾秒鐘就跑完了比 RTL 仿真快好幾個數(shù)量級。C 寫狀態(tài)機有兩種風(fēng)格switch-case 大法適合狀態(tài)少的情況表驅(qū)動適合狀態(tài)多、轉(zhuǎn)換規(guī)則多的協(xié)議。CHI 七態(tài)和幾十種事件的笛卡爾積是有規(guī)律的表驅(qū)動最合適。typedef enum { I, UC, UCE, UD, SC, SD, UDP } ch_state_t; typedef enum { EVT_READ_SHARED, EVT_READ_UNIQUE, EVT_WRITE_PARTIAL, EVT_WRITE_FULL, EVT_PROBE_INVALIDATE, EVT_WRITEBACK } ch_event_t; typedef struct { ch_state_t cur; ch_event_t evt; ch_state_t next; } trans_entry_t; static const trans_entry_t ch_state_table[] { { I, EVT_READ_SHARED, SC }, { I, EVT_READ_UNIQUE, UD }, { I, EVT_WRITE_FULL, UD }, { SC, EVT_PROBE_INVALIDATE, I }, { SC, EVT_READ_UNIQUE, UD }, { UCE, EVT_WRITE_PARTIAL, UD }, { UD, EVT_WRITEBACK, I }, }; ch_state_t ch_next_state(ch_state_t s, ch_event_t e) { for (size_t i 0; i ARRAY_SIZE(ch_state_table); i) { if (ch_state_table[i].cur s ch_state_table[i].evt e) return ch_state_table[i].next; } return s; // 未定義跳轉(zhuǎn)默認(rèn)保持 }這套 C 模型還能順便做覆蓋率統(tǒng)計比如統(tǒng)計每個狀態(tài)被訪問的次數(shù)、每條跳轉(zhuǎn)路徑被觸發(fā)的次數(shù)RTL 里有沒有覆蓋到的死代碼在 C 模型階段就能提前暴露。很多人是從 STM32 按鍵消抖、JTAG TAP 狀態(tài)機這些入門 demo 認(rèn)識狀態(tài)機的到了緩存一致性這個級別狀態(tài)機規(guī)模大了幾十倍但方法論是相通的狀態(tài)清晰、事件明確、跳轉(zhuǎn)表可查。5.4 驗證讓狀態(tài)機在隨機激勵下裸奔狀態(tài)機寫對只是第一步怎么證明它對才是最花時間的。協(xié)議驗證的主流手段是隨機激勵 參考模型比對。參考模型就是上面那種 C 狀態(tài)機它跑出一個期望狀態(tài)RTL 每拍輸出一個實際狀態(tài)兩邊一旦不一致仿真立刻停下來方便后端定位。還有一個很關(guān)鍵的經(jīng)驗是定向標(biāo)注場景要單獨做。UCE 和 UDP 這兩個特殊狀態(tài)在純隨機激勵下很難被密集命中因為你得先構(gòu)造出 full-line write、部分寫、字節(jié) mask 組合這些特定前提。我習(xí)慣為每個特殊狀態(tài)單獨寫一組定點用例模擬真實場景里最惡劣的訪問模式比如同一行被兩個 die 輪流部分寫中間夾雜 snoop probe。這種用例在 reference spec 里寫不清楚只有干過活的人才知道要測。6. 協(xié)議級 Debug 實戰(zhàn)六個踩過的坑6.1 把 UCE 當(dāng)成 UC 用數(shù)據(jù)直接錯這是新手最容易犯的錯。UCE 行數(shù)據(jù)是空的但狀態(tài)名里帶著 Clean很多人想當(dāng)然認(rèn)為可以直接讀。實際上一旦有 CPU 請求讀這個 UCE 行控制器的首要任務(wù)是向 Home Node 發(fā)起數(shù)據(jù)請求把這個行的數(shù)據(jù)補回來然后才能對外響應(yīng)。我們把 UCE 的讀響應(yīng)路徑漏掉了結(jié)果 CPU 拿到的是隨機數(shù)據(jù)仿真早期根本不會暴露跑到帶 DDR 模型的大系統(tǒng)測試才炸。這個教訓(xùn)我寫進團隊 checklist 里了遇到 UCE 一律先問數(shù)據(jù)有沒有補齊沒有第二步。6.2 SD 狀態(tài)的讀響應(yīng)路徑配錯SD 是共享臟owner 掌握著最新數(shù)據(jù)。問題出在 Home Node 的 snoop 轉(zhuǎn)發(fā)粒度上。我們當(dāng)時做了一層優(yōu)化某些讀事務(wù)如果請求的地址命中了 owner 的 SD 行理論上 owner 可以直接把數(shù)據(jù)轉(zhuǎn)發(fā)給請求者不需要先回到內(nèi)存。但 snoop 過濾器的表項只跟蹤了行地址沒跟蹤字節(jié)范圍導(dǎo)致部分字節(jié)命中時也強制走 ownerowner 卻只持有部分字節(jié)的有效數(shù)據(jù)數(shù)據(jù)就錯了。修正方案是讓 snoop 轉(zhuǎn)發(fā)邏輯同時檢查地址和字節(jié) maskowner 判斷數(shù)據(jù)覆蓋范圍覆蓋不了的部分再回內(nèi)存補齊。SD 的 owner 路徑必須和 UDP 的 mask 邏輯一起驗證這兩個狀態(tài)在真實系統(tǒng)里經(jīng)常聯(lián)手給你上課。6.3 CHI 的 RSP/DAT 亂序把 reorder 緩沖省沒了CHI 協(xié)議里同一事務(wù)的 RSP 和 DAT 到達(dá)請求者的順序是有講究的為了省面積我們最初設(shè)計只在數(shù)據(jù)通道做了按事務(wù) ID 的隊列管理RSP 通道則走捷徑。結(jié)果壓力測試下出現(xiàn)了 RSP 先到、DAT 后到的場景請求者看到 RSP 以為數(shù)據(jù)已經(jīng) ready讀出來一個舊值。這不是協(xié)議理解錯誤是 RSP/DAT 順序約束在設(shè)計時被低估了。后來在 RN 側(cè)增加了一個很小的 reorder buffer專門處理 RSP 和 DAT 的配對面積多花了 5%但正確性徹底穩(wěn)了。省面積可以理解但協(xié)議級順序約束的賬要算清楚再省。6.4 TileLink probe 風(fēng)暴與活鎖Rocket Chip 的 L2 用 TileLink-CCPU 頻繁 Acquire 同一行L2 做替換時又頻繁 Release兩者互相搶通道出現(xiàn)了一種 probe 風(fēng)暴manager 不斷發(fā) Probeclient 不斷回 Release事務(wù)永遠(yuǎn)結(jié)束不了。從狀態(tài)機看每個狀態(tài)跳轉(zhuǎn)都是合法的但整個系統(tǒng)在跑圈。解決策略是給替換 Release 一個更高的仲裁優(yōu)先級——替換不能成功新事務(wù)就沒法分配空間這是典型的活鎖。事后看協(xié)議驗證時就應(yīng)該在激勵里注入地址熱點讓所有核死磕同一行這類場景靠均勻隨機根本測不出來。6.5 CXL.cache 的 E 到 S 降級沒通知 hostCXL.cache 場景里設(shè)備緩存原來持有 EExclusive狀態(tài)因為本地容量壓力需要把行降級成 S 甚至 I但軟件側(cè)認(rèn)為設(shè)備還在獨占。host 的 snoop filter 變得不準(zhǔn)確后續(xù)對同一行的寫操作沒有正確 invalidate 設(shè)備設(shè)備就拿著過期數(shù)據(jù)回應(yīng)本地請求。根因是設(shè)備的 cache line 狀態(tài)機和 snoop filter 的同步邏輯不同步降級時漏發(fā)了一個通知。這個 bug 在純 CXL 模擬器里很難復(fù)現(xiàn)因為模擬器的延遲模型太友好真實鏈路延遲一上來臨界區(qū)窗口放大問題就現(xiàn)形了。經(jīng)驗是設(shè)備側(cè)一致性相關(guān)狀態(tài)變化一律顯式同步不要依賴時序巧合。6.6 死鎖REQ 占住DAT 等 REQ最經(jīng)典的三通道死鎖。某個長事務(wù)占用了 REQ 通道的某個虛擬通道而它需要的數(shù)據(jù)響應(yīng)要先在 RSP 通道上讓另一個事務(wù)插隊才能完成如果 RSP 通道又被一個等待 REQ 通道的事務(wù)堵住一圈循環(huán)下來所有通道都動不了。CHI 理論上是按字節(jié)通道設(shè)計成無死鎖的但前提是各通道的 credit 和虛擬通道分配合理。我們的教訓(xùn)是虛擬通道的映射必須按事務(wù)類型隔離尤其是 posted 類事務(wù)和非 posted 類事務(wù)不能混用同一緩沖。排查死鎖最快的方法是看各通道的 credit 占用統(tǒng)計哪個通道 credit 歸零且長時間不恢復(fù)就是它被堵死的位置。最后說幾句掏心窩的話這些坑寫出來輕飄飄的每一個都是十幾個通宵換來的。做互連協(xié)議有個很反直覺的規(guī)律越接近協(xié)議標(biāo)準(zhǔn)的實現(xiàn)越容易在工程細(xì)節(jié)上翻車。UCE 數(shù)據(jù)有沒有補齊、SD 的 mask 匹配沒匹配、RSP/DAT 的順序約束守沒守住這些不是 spec 里畫個箭頭就能教會你的必須親手把狀態(tài)機跑起來被 bug 咬幾口才長記性。所以我一直建議剛?cè)胄械呐笥褎e急著上大芯片項目先從 TileLink 的 RTL 開始看它開源、簡單、完整能讓你把 MESI 那一套改造成七態(tài)的心路歷程全部走一遍。等你理解了七態(tài)為什么存在、PBR 路由為什么不能只查表再看 CHI、CXL、UCIe 這些龐然大物就只是尺度問題不是認(rèn)知問題了。