來源：內容由半導體行業觀察（ID：icbank）轉載自公眾號網絡交換FPGA，作者：brunella等，謝謝。
人類自誕生之日起，就常常因為一些事情經常這樣或那樣做而形成一種慣例，我們稱這種慣例為習慣。CPU就是這麼一種產物，什麼都可以做，靈活，好用。但隨着定製化芯片的不斷發展，是否真的需要CPU逐漸成為一種值得考慮的問題。尤其在定製計算領域，CPU的計算能耗比過低已經成為事實，甚至有幾個數量級的差別。如本公眾號之前曾發布的喚醒芯片的介紹"小愛同學"之類語音喚醒芯片相關技術介紹，都是不帶CPU的超低功耗芯片。那麼，在常常以功耗過大被詬病的數據中心應用日益頻繁的DPU芯片，是否也可以不帶CPU呢？本文就介紹了一篇2022年5月19日發布在https://arxiv.org/pdf/2205.08882.pdf網站上的一篇文章。
自從計算誕生以來，我們一直依賴於CPU驅動的架構。然而，如今這種依賴受到製造限制（CMOS縮放）、性能預期（時鐘頻率停滯、圖靈稅）和安全問題（微架構攻擊）的挑戰。為了重新構想我們的計算架構，在這項工作中，我們採用了一種更激進但實用的方法，並提議消除CPU及其設計包袱，並將計算的三個主要支柱（即網絡、存儲和計算）集成到一個名為Hyperion的單一、自託管、統一的無CPU數據處理單元（DPU）中。在本文中，我們介紹了Hyperion的案例、它的設計選擇、最初的工作進展細節，並從系統社區尋求反饋。
自從計算誕生以來，我們一直在圍繞作為主要工作機器的CPU來設計和構建計算系統。這個主要架構為我們提供了很好的服務。然而，隨着從Moore和Dennard的縮放中獲得的收益開始減少，研究人員已經開始將目光從以CPU為中心的設計轉向加速器和特定領域的計算設備，如GPU[26，73，115]、FPGA[84，111]、TPU[72]、可編程存儲器[87，116，121]和智能網卡[50，128]。2017年的圖靈獎得主，體系結構宗師Hennessy和Patterson在2017年的Turning Award演講中宣布，在廣泛的主流計算中使用特定領域的計算設備預示着計算機體系結構的黃金時代的來臨[64]。
John Hennessy（左）和David Patterson 拿着他們合著的《計算機體系架構：量化研究方法》，照片的拍攝時間大約是1991年。來源：ACM
表1.在網絡(net)、存儲(sto)和加速器(accel)設備集成方面的相關工作(§4)
然而，即使在這個黃金時代，CPU仍然處於管理數據流[113]（數據複製、I/O緩衝器管理[100]）、加速器（例如PCIe枚舉[120]）以及在OS級別（分組、請求、文件）與設備級別（地址、位置）之間進行轉換的關鍵路徑中[14、66、125、129]。表1展示了先前方法的概述。此外，在保持系統資源(dram、內存映射、 tlbs)的 cpu 和加速器視圖一致和安全的情況下，總是完成加速器集成(通過虛擬化或多路復用)。儘管這種集成是必要的，但它給加速器管理帶來了複雜性，並使CPU成為最終的資源仲裁器。與加速器和I/O設備相比，CPU性能預計不會大幅提高[101]，甚至會隨着每次微架構攻擊修復而下降[23，81]。我們不是第一個提出與CPU驅動的計算架構相關的問題的人[42，101]。儘管意識到了這一點，但CPU驅動的設計以及CPU仍然處於端到端系統構建的關鍵路徑中，因此無法逃脫阿姆達爾定律[64]的影響。
第一原則推理提出了解決方案：沒有CPU的系統，即零CPU或無CPU架構。像零cpu這樣全新的計算架構將需要對計算硬件(總線、互連、控制器、DRAM、存儲)、系統軟件和應用程序進行徹底的、顛覆性的重新設計。此方法先前的一個示例是用於模擬的MSR BEE3系統[44]。最近的一個例子是ETH的Enzian系統，它設計了一個混合CPU-FPGA雙插槽系統[41]。Enzian的論文記錄了設計這樣一個系統所付出的巨大工程努力，其中所有板組件都需要重新設計，以將FPGA作為協處理器與CPU集成。此外，這種以CPU為中心的思想鼓勵我們繼承和集成以CPU為中心的硬件和軟件選擇，以實現以加速器為中心的設計，而無需重新評估這些選擇是否有意義和/或是否可以簡化（參見§2）。
在這項工作中，我們採用了一種更實用的方法，並研究了稱為Hyperion的統一NIC-FPGA存儲數據處理單元（DPU）的設計（圖1）。Hyperion的目標是在DPU內建立端到端的硬件控制/數據路徑，而不涉及任何CPU。Hyperion的獨特設計允許我們考慮構建一個獨立的、自包含的DPU，其中不需要主機系統來運行它，從而降低了能源成本並增加了封裝密度。這種直接連接網絡的FPGA模型以前也曾使用過[69，111，123，133]。在本文中，我們介紹了這種獨立DPU且沒有CPU的情況（§2），並介紹了與硬件集成（§3.1）、系統軟件（§3.2）以及客戶端接口和工作負載（§3.3）相關的設計選擇。
CPU驅動的設計有其明顯的優點，對於一般計算中的每個工作負載，都不建議將其消除。但是，對於專門的數據中心工作負載（數據並行、加速器兼容、分解），必須重新評估CPU的可用性。有三個主要動力促使我們考慮無CPU的DPU：
首先，一個CPU的時代已經結束（設計、製造和熱限制[34，51，63]），前進的方向是專業化與可重構的硬件和加速器。CPU的通用性具有開銷（即，圖靈稅），這阻礙了性能或效率的專門化。例如，在DNA序列比對中，Smith Waterman算法的計算需要37個周期，40個指令(35個算法，15個加載/存儲)，81納焦耳的能量(在14nm的CPU上)。相比之下，在專用的40nm ASIC上進行計算需要一個單周期指令，其能量為3.1皮焦耳[131]。針對任何工作負載的CPU的通用性和過度工程設計也導致了較差的片上資源利用率[52]，未使用的硅[51,63]，以及更高的安全風險[81]。與此同時，隨着開源EDA流程和項目的出現[7,8]，探索工作負載專用的硬件設計(帶或不帶CPU)變得更容易實現和負擔得起。
其次，保持CPU驅動設計的直接後果是繼承其內存尋址選擇、轉化以及保護機制，如虛擬內存、分頁和分段[45]。當諸如FPGA之類的加速器作為外部設備[39]或協處理器[41]連接到CPU時，存在提供/移植熟悉的存儲器抽象（如統一虛擬存儲器[84]和/或共享存儲器[94]）的誘惑。這種設計需要與其他CPU附加內存抽象（如頁表和TLB、虛擬化、大型頁面、IOMMU等）進行複雜集成，同時保持這種集成與系統的CPU視圖一致[84，94]。此外，在具有加速器和異構CPU的現代計算平台上管理物理內存（或平面、統一物理地址空間的假象）是一項重要而複雜的工作[10]。因此，在這項工作中，我們認為避開CPU及其設計包袱，我們可以探索新的內存管理設計，例如編譯器/語言輔助解決方案，甚至直接在物理地址上[126]。
最後，以CPU為中心的設計鼓勵活動資源分解，其中資源仍然連接到管理分解邏輯的主機CPU。這種設計導致分解粒度更粗，軟件複雜且臃腫[56]，處理器/內存緊密集成[61，122]。以實現韓等人所描繪的願景。在他們開創性的HotNet 13論文[62]中，重新推動了被動分解，其中分解邏輯/智能取決於客戶端，並且遠程資源僅儘可能快地服務請求[12，36，61，122，130]。被動分解促進了網絡連接模型，其中內存、存儲、DPU和ASIC直接連接到網絡，並提供了與細粒度計算模型（如無服務器）更好的匹配[37，107]。它還使得系統設計者能夠重新思考（I）用於發現和配置協議的網絡協議（例如，彈射器結構[111]）；（II）用於分布式資源分配和訪問的客戶端和遠程服務器之間的工作劃分（例如，Clio[61]，DUA[123]）；以及（III）具有隔離、多路復用機制（例如，組卸載和存儲器重新分配[12，77，93]）的卸載友好。
總結：在這項工作中，我們提出了一個消除CPU及其設計包袱的案例，並認為它的消除可以帶來實質上的簡單性，並提供性能/能量優勢。我們設計和實現Hyperion的嘗試就是朝着這個方向邁出的一步。
Hyperion是一個獨立的網絡連接DPU，它將100 Gbps以太網NIC、FPGA和NVMe存儲設備統一在單個DPU中。圖1顯示了帶有FPGA板和附加NVMe SSD的Hyperion的整體架構。
3.1硬件設計在商業上，NIC和存儲設備（例如NVM Express）可作為單獨的PCIe設備提供。兩者之間的通信需要通過PCIe根複合體與來自CPU（如果支持，例如NVMe控制器內存緩衝區（CMB）[21]）的P2P DMA進行控制協調，PCIe根複合體通常駐留在CPU複合體上（將其保持在循環中）。為了使DPU自給自足，Hyperion在FPGA板上運行帶有NVMe控制器的PCIe根複合體，該控制器直接連接到100 Gbps網絡。FPGA PCIe通道通過PCIe分叉連接（x16）到現成的NVMe存儲設備。因此，對存儲器的所有訪問都通過FPGA進行。有了這樣的設計，Hyperion現在擁有了一條從網絡到FPGA再到存儲設備的端到端硬件路徑。端到端硬件路徑可以專用於具有優化的網絡傳輸（TCP、UDP、RDMA、HOMA[104]）、存儲API（NVMoF[117]、i10 [68]、ReFlex [80]、KV-SSD [27]）的工作負載，FPGA上具有任意存儲功能(壓縮，指針跟蹤，重複數據刪除，或應用程序定義的代碼)。
為什麼選擇FPGA？三個因素決定了FPGA的選擇：
1.特定於應用程序的可重構性：FPGA的使用允許我們重新配置硬件（深流水線、展開循環、數據並行、大型緩存），以實現特定於應用程序的邏輯的最佳可能實現。ASIC具有類似的優點，但需要較高的初始投資和製造成本。此外，由于越來越多的趨勢是在附近放置數千個特定於工作負載的處理單元（PU）（例如，Cerebras[2]、Telsa Dojo[6]），因此PU和存儲器（SRAM、DRAM或HBM）之間的距離至關重要。在這裡，我們認為基於FPGA的設計提供了最佳的折衷方案。
2.改進的FPGA系統軟件支持：管理FPGA的主要挑戰來自於使用硬件描述語言（HDL）仔細管理工作負載的流水線執行。隨着高質量DSL[18，75，82，118]、操作系統外殼[84]和HDL編譯器（hXDP[35]）的出現，為高數據速率（100+Gbps）生成高質量HDL變得更加經濟實惠[53，92]。整個FPGA的編譯和調試過程也得到了改進[95，136]。
3.可預測的能效性能：與CPU和I/O設備不同，後者以細粒度的基於時間的統計多路復用（微秒到納秒）為目標，以最大限度地提高資源利用率，而FPGA則以更粗糙的時間尺度（10-100毫秒）為目標，甚至是將資源分配給租戶的空間多路復用。這種共享模型有助於構建高度可預測的執行流水線，一旦相關的比特流被發送到FPGA，電路就會在沒有任何外部干擾的情況下運行特定的時鐘頻率[70，89]。FPGA的使用已被證明是節能的[35，112，116]，因為其能耗與活動和使用的可編程LUT以及工作頻率成比例。未使用的邏輯元件不消耗任何能量，導致部署消耗10-20瓦，這比服務器級機器小一個數量級[70]。
除了FPGA的選擇之外，Hyperion還將NVM Express（NVMe）用於塊SSD，將以太網用於網絡，以及將PCIe用於FPGA和SSD之間。這些選擇取決於實用性和所需的工程努力。例如，選擇PCIe而不是其他高性能本地互連（CXL、CAPI）或網絡（TrueFabric[55]），可以隨着工作負載需求的增加而修改。
3.2軟件和編程由於沒有CPU和傳統的操作系統，在Hyperion中使用提升的權限進行傳統的資源管理來協調對共享資源的訪問將是具有挑戰性的。因此，我們必須重新協商硬件、編譯器和應用程序之間的分工，讓編譯器發揮主導作用。編譯器的角色在這裡並不罕見。已經表明，編譯器輔助設計可以幫助傳統的操作系統角色，例如上下文切換[48，88，97]，內存虛擬化[126]，單級內存/存儲[30，67]，並行[35]，虛擬化和多租戶[75，138]。
使用這種以編譯器為中心的方法，我們冒着VLIW處理器重複故障的風險。然而，我們認為有兩個根本性的轉變對我們有利。首先，特定於領域/工作負載的架構是常見的，並且相關的語言（例如，OpenCL，Chisel[18]）和編譯器被廣泛用作標準。在共同設計特定領域或特定工作負載的硬件/軟件方面有重要的研究和商業利益。其次，與VLIW處理器不同，DPU(特別是FPGA驅動的)的目標不是為所有/任何工作負載提供性能，因此，限制了優化設計空間。例如，hXDP已經證明，使用簡單語言（eBPF）的編譯時啟發（Bernstein條件）可以用於使用VLIW軟核處理器的數據包處理工作負載的自動並行[35]。
受LLVM項目的啟發，在本文中，我們認為FPGA編程需要使用獨立於加速器的中間表達（IR）語言來解耦前端（應用程序邏輯）和後端（HDL代碼）。IR可用於對程序的正確性和安全屬性進行推理，並對指針調整和特權調用進行編譯器輔助轉換。由於三個關鍵原因，我們認為擴展Berkeley分組過濾器（eBPF）[40，99]語言是這種IR的合適匹配。首先，eBPF不依賴於特定的應用程序域，它用於網絡[65，135]、跟蹤[59]、緩存[58]、安全[74]和存儲[20，28，85，141]。它還得到了健康成長的社區（Cilium，EBPF基金會）的支持，從而建立了專門知識和知識庫。第二，由於eBPF指令集的簡化特性，可以對其執行進行驗證和推理。Linux內核已經附帶了eBPF驗證器[127]（具有簡化的符號執行檢查）。最後，eBPF支持多個硬件設備（如x86、ARM或FPGA）的高效代碼生成（通過JITing），從而鞏固了其作為獨立於加速器的地位，統一了異構計算的IR[76]。請記住，這裡我們對eBPF採取了更廣泛的立場，其中Linux內核實現是eBPF執行環境的許多可能實現之一。例如，有用戶空間BPF虛擬機[9]、檢查器[57]和特定於應用程序的ISA擴展[35]。除了eBPF之外，我們還考慮P4，另一種用於網內加速（NIC和交換機）的流行編程語言。然而，P4程序是圍繞數據包處理和網絡抽象設計的。在有限的功能中（只有過濾和轉發），有P4到eBPF編譯器可用，儘管P4對於一般數據處理的通用性還有待探索。
Hyperion支持任何支持eBPF的編程語言作為前端。然後，它使用Clang/LLVM從前端生成eBPF IR。eBPF IR然後被傳遞到兩個階段的編譯過程。在第一階段，eBPF IR通過開源hXDP編譯器進行並行和優化VLIW轉換[17，35]。在第二階段中，優化的eBPF IR通過eBPF-to-HDL編譯器用於最終的HDL代碼生成。與hXDP不同，Hyperion直接運行HDL代碼，而不是作為FPGA上的VLIW軟核處理器。
除了將應用程序提供的代碼基本編譯為HDL之外，還存在與以下方面相關的挑戰：（I）安全的多租戶執行；以及（II）數據中心資源的FPGA配置、管理和可訪問性[123]。由於在FPGA中執行時沒有主機系統資源(CPU或操作系統上)需要保持一致和安全，因此過去的許多設計選擇都可以簡化。我們建議利用FPGA資源的槽式切片[75]和編譯器來進行工作負載劃分[138]。Hyperion運行一個配置內核，該內核可以通過網絡接收授權的FPGA位流，並為其分配切片。
3.3客戶端接口和工作負載為了提供可特殊化的客戶端接口，Hyperion從Willow中獲得靈感[121]，Willow開創了支持RPC的可編程SSD接口，其中用戶提供應用程序端和SSD端RPC存根。這種靈活的設計可以支持網絡和存儲接口的任何所需的專門化。例如，我們可以構建能夠支持Corfu共識協議[19，134]、塊級NVMoF訪問、NFS加速或應用程序提供的代碼的線內碰撞/近數據執行（B+/LSM樹搜索、壓縮和插入、文件系統遍歷、事務）的網絡連接SSD[116，139]。在這裡，我們可以利用客戶端驅動的請求路由[91]和無共享的運行到完成數據路徑[24]來提高性能。
我們主要關注Hyperion的三個應用程序類。首先，高容量應用程序（如fail2Ban[4]）檢查和寫入網絡流量，並將身份驗證/惡意數據記錄到連接的SSD。此類應用程序必須在緊張的時間預算（每秒數以百萬計的數據包）下處理大量的數據包數據。第二，對延遲敏感的應用程序，如網絡指針追蹤。在分解存儲中，在B+樹、擴展樹、LSM樹（在許多數據庫、文件系統和鍵值存儲中使用[109]）上的指針追蹤導致多個網絡RTT具有顯著的性能下降[85]。最後，網絡連接的SSD可以導出應用程序定義的高級容錯，例如樹、查找表[27]、分布式/共享日誌[19，134]、原子寫入[105]、並發附加[31]、緩存[58]以及並發數據結構和事務接口（類似於Boxwood[96]）。
這裡的一個主要挑戰是處理過程中多個功能的可組合性和FPGA上的狀態管理。通常，與FPGA的存儲集成是在塊級完成的，以便對數據流進行無狀態數據處理（如grep）。因此，需要適當的API和來將高級存儲與FPGA/BPF上的有效狀態管理集成，例如文件系統[28，116，119]、文件/數據格式集成[86，106]、數據緩存[58]、OOS調度（存儲/網絡資源的優先級共享）、檢查點、去重複、加密等。我們正在為FPGA代碼構建共享庫等模塊。
3.4現狀我們正在使用Xilinx Alveo U280板製作Hyperion原型，該板具有2x100 Gbps QSFP[1]。我們設計了一個PCIe cross overboard[46]，用於將4個NVMe設備連接到帶電源的U280。
當加電並且FPGA JTAG自測試通過時，當前系統在沒有任何CPU的情況下以獨立模式啟動。該板目前通過USB連接到主機系統進行編程，但是，我們正在開發一個操作系統外殼和網絡上的控制路徑，它也可以完全獨立地對FPGA進行編程，通過FPGA的內部配置訪問端口（ICAP）利用部分動態重新配置。我們選擇使用B+樹關鍵值存儲作為Hyperion的首批應用程序之一。我們已經編寫了一個XDP兼容的B+樹，它在內核中的XDP路徑（內存）上運行。在Hyperion上，樹將其所有數據直接存儲在NVMe設備上，並將通過網絡提供get/put/delete請求。
我們硬件的原始延遲為：L2網絡RTT~1µs，NVMe延遲為[5-8]µs。目前，我們不進行任何緩存，因此，所有的樹訪問都會導致對存儲設備的訪問。在此設置下，平均（預期）查找延遲為：O（1+（tree_height ×8）µsec））。根據過去使用網絡包處理管道的經驗，我們期望Hyperion支持每秒1百萬次查找操作，儘管峰值性能取決於並行運行的PCIe通道、NVMe設備和FPGA內核的數量。在我們當前的編譯過程中，B+樹實現生成1000多個管道階段。這是我們用工具鏈測試過的最大設計之一，它對FPGA上的資源可用性提出了挑戰。儘管我們相信，即使是這種未經優化的B+樹實現也可以適用於FPGA，並且有足夠的優化空間來實現真正的多租戶。
Hyperion 的原型使用 xilinx u280 fpga 和 nvme 設備，如圖2和圖3所示。
圖2: hyperion: u280 fpga-side up。圖3: hyperion: ssd-side up。
Nider和Fedorova還質疑了系統中「最後一個CPU」的效用，並研究了系統管理總線的設計，以接管OS/CPU的職責[101]。表1顯示了成對設備交互的努力，例如GPU與存儲器[22，25，26，113，124]、GPU與網絡[43，78，102]、加速器到/從存儲器[13，15，16，90]、智能NIC[50，110，128]和網絡存儲訪問[79，117]。用（1）網絡 [35，53，132，142]以及（2）存儲[116，119，121] 探索FPGA。使用Endance DAG卡[49]、Netronome[71]、Combo6[98]將BPF卸載到NIC/FPGA進行處理，但主要限於監控和流量塑形。FPGA輔助的KV存儲考慮了網絡和KV處理(內存)的緊密集成[32，38，69，89]以及NAND閃存的選擇性集成(例如BlueDB和XilinxKV[33，137])。最接近Hyperion的設計靈感之一是LeapIO[90]，它將NVMe閃存與RDMA NIC和ARM SoC集成在一起。Hyperion和LeapIO有着相似的動機（成本、能源和性能效率），但是Hyperion可以避免LeapIO的許多設計複雜性（主機x86 CPU和ARM SoC的交互）。Hyperion的目標是更廣泛的設計空間，我們考慮統一可重新配置的硬件（此處為FPGA）、網絡傳輸（100 Gbps以太網）和存儲（NVMe閃存）。這種統一提供了多種硬件/軟件專業化認證，以支持多種工作負載需求。Hyperion仍處於早期原型階段。從系統社區，我們尋求對以下問題的反饋：
(1) 淘汰CPU是值得追求的目標嗎？在本文中，我們提出了一個有爭議的移除CPU的案例，我們相信，隨着最近硬件和軟件的進步，現在是重新評估CPU的作用及其帶來的設計包袱的時候了。然而，我們有興趣聽取反駁意見。我們明白，除了技術之外，運營成本和複雜性可能會限制這一想法的實現。從無CPU設計中獲得的性能、能源和封裝效率達到什麼水平才是值得的？消除CPU端中介還需要FPGA工具鏈、語言和編譯器發揮更大的支持作用，這一作用以前由主機CPU和操作系統分擔。FPGA工具鏈準備好了嗎？
(2) 構建分布式Hyperion應用程序的合適客戶端接口是什麼？除了硬件和單個DPU之外，構建可在多個DPU上執行的分布式無CPU應用程序還需要哪種應用程序級接口/抽象？被動的資源分解將控制協調的責任放在客戶端。多個客戶端要麼自己協調，要麼使用外部服務[11，70]。但是，為了充分發揮Hyperion的潛力，應用程序在與Hyperion交互時還應減少客戶端CPU/OS的參與（例如，使用RDMA或DPDK）。如何構建這種獨立的、被動分解的DPU的分布式應用程序和可組合的服務生態系統？
(3) 多租戶雲中的運營複雜性？在數據中心、硬件和軟件出現故障。租戶不受信任。低效率和停機的成本很高。因此，如何確保Hyperion能夠在FPGA中提供安全的多租戶執行[140]？如何使用Hyperion減少微架構攻擊？Hyperion的微架構資源是否可以或應該與租戶明確管理，以確保與Hyperion DPU充分隔離[114]？*免責聲明：本文由作者原創。文章內容系作者個人觀點，半導體行業觀察轉載僅為了傳達一種不同的觀點，不代表半導體行業觀察對該觀點讚同或支持，如果有任何異議，歡迎聯繫半導體行業觀察。
今天是《半導體行業觀察》為您分享的第3048內容，歡迎關注。
★從無到有，做好一顆芯片要幾步？
★國產半導體光刻膠野望
★日本功率半導體的「焦慮」
『半導體第一垂直媒體』
實時 專業 原創 深度
識別二維碼，回復下方關鍵詞，閱讀更多
晶圓｜集成電路｜設備｜汽車芯片｜存儲｜台積電｜AI｜封裝
回復 投稿，看《如何成為「半導體行業觀察」的一員 》
回復 搜索，還能輕鬆找到其他你感興趣的文章！
留言列表