Hot Chips 2026: Het Near-Memory Compute CXL-apparaat van XCENA en Samsung

Geheugenuitbreiding is al jaren een aantrekkelijk concept en is relevanter dan ooit, aangezien ML-modellen een onverzadigbare honger hebben naar geheugencapaciteit. Als reactie hierop heeft XCENA samengewerkt met Samsung om een CXL-geheugenuitbreidingsapparaat te creëren dat ook SSD's kan hosten en berekeningen (compute) kan uitvoeren. Het apparaat heet de MX1, waarbij MX staat voor "Memory Xcelerator".

Hardware en connectiviteit

Wat betreft de geheugenuitbreiding kan de MX1 tot 2 TB aan DDR5-geheugen hosten en verbindt hij met de host via een PCIe 6/CXL 3.2 x8-interface. De MX1 heeft hiermee een bandbreedte van 128 GB/s naar de host, oftewel 64 GB/s in elke richting. XCENA stelt daarnaast acht downstream PCIe 6-lanes beschikbaar die gebruikt kunnen worden om SSD's aan te sluiten. SSD-opslag kan als geheugen worden gepresenteerd, waarbij het aan het MX1-apparaat gekoppelde DRAM fungeert als cache. De combinatie van DDR5-slots en downstream PCIe-lanes stelt de MX1 in staat om een enorme hoeveelheid geheugencapaciteit zichtbaar te maken voor de host. De meest opwindende functie van de MX1 is echter de aanzienlijke hoeveelheid ingebouwde rekenkracht.

Compute-architectuur

De chip van de MX1 bevat 3072 RISC-V-cores, verdeeld in clusters van 32 cores die L2-caches en een data-TLB delen. Sets van vier clusters vormen een "subsystem", wat de kleinste eenheid is voor taaktoewijzing (job allocation). De MX1 heeft 24 subsystems, waardoor hij 24 onafhankelijke taken tegelijkertijd kan uitvoeren. Een intern NoC (Network-on-Chip) verbindt de subsystems met de L3-cache en het geheugen. Twee Arm Cortex A53-cores verzorgen de controlefuncties. De MX1 is gefabriceerd met behulp van het 4nm-proces van Samsung en verbruikt 40 W, wat impliceert dat elke RISC-V-core iets minder dan 13 mW verbruikt. Het volledige bord verbruikt 90 W, inclusief het stroomverbruik van 4 DIMM's.

XCENA maakt gebruik van veel kleine cores omdat ze zich richten op data-parallelle workloads. Hierbij is de prestatie van een enkele thread minder belangrijk dan het benutten van een hoge geheugenbandbreedte bij een maximale energie-efficiëntie. Deze strategie vertoont parallellen met de Intel Xeon Phi, die eveneens een groot aantal laaggeklokte, relatief zwakke cores gebruikte voor zeer parallelle taken.

Cache-hiërarchie binnen een cluster

Elke RISC-V-core maakt gebruik van in-order execution en draait op een bescheiden 1,1 GHz. De cache-hiërarchie van XCENA lijkt bijna op die van een GPU, omdat men de overhead van adresvertaling wil vermijden en de cache-deling op de hogere niveaus sterk varieert:

• L1 Data Cache: Elke core heeft een virtueel geadresseerde L1-datacache van 4 KB. Geheugentoegangen aan de data-zijde gaan niet via adresvertaling, tenzij er een L1D-miss optreedt.
• L2 Data Cache: 128 KB L2-datacaches worden gedeeld binnen een cluster, evenals de TLB's voor het versnellen van de adresvertaling. De L2-datacache is virtually indexed and physically tagged (VIPT), vergelijkbaar met L1D-caches in veel conventionele CPU's.
• L1 Instruction Cache: Sets van vier RISC-V-cores delen een instructiecache van 8 KB. XCENA streeft ernaar om kernel hot loops binnen deze instructiecache te houden.
• L2 Instruction Cache: Een L2-instructiecache van 128 KB op clusterniveau handelt grotere instructie-footprints af.

Instructie-fetches werken direct op fysieke adressen en maken geen gebruik van virtueel geheugen. Instructietoegangen hebben daarom geen adresvertaling of TLB's nodig. XCENA reserveert vooraf gedefinieerde fysieke apparaatadressen voor code en beperkt de program counter tot die regio's. Dit voorkomt dat de RISC-V-cores per ongeluk naar data springen. XCENA regelt isolatie op procesniveau door taken te isoleren op de grenzen van het subsystem (128 cores). Vermoedelijk verdelen ze ook de coderegio, zodat elk subsystem zijn eigen codesegment heeft, wat voorkomt dat een proces per ongeluk de code van een ander uitvoert.

Programmeringsmodel en virtueel geheugen

Het programmeringsmodel van de MX1 vertoont parallellen met OpenCL of CUDA. Eén kernel wordt vele malen aangeroepen, en elke aanroep gebruikt een index om te bepalen welke data verwerkt moet worden. Specifiek is mu::getTaskIdx() analoog aan de getglobalid() van OpenCL. Dit model stimuleert het delen van code over veel cores, waardoor het delen van L1-instructiecaches zinvol is. Als een loop klein genoeg is, kunnen de vier cores die een instructiecache delen tegelijkertijd hetzelfde adres ophalen, waardoor de instructiecache meerdere fetches kan bevredigen met een broadcast read.

Aan de data-zijde maakt de MX1 gebruik van virtueel geheugen en werkt hij met dezelfde virtuele adressen als de hostcode. Hostcode en MX1-code kunnen dus pointers delen, vergelijkbaar met de SVM (Shared Virtual Memory) van OpenCL. De software van XCENA stelt paginatabellen in om dezelfde mappingen als de host te behouden.

De TLB heeft 1024 vermeldingen voor pagina's van 64 KB en 8 vermeldingen voor pagina's van 1 GB. Pagina's van 64 KB bieden een grotere TLB-dekking dan typische pagina's van 4 KB. Hoewel besturingssystemen meestal kleinere paginagrootten gebruiken om overhead te verminderen bij paging naar schijf, verwacht XCENA dat het OS CXL-geheugen een speciale behandeling geeft. Grotere paginagrootten zijn zinvol voor een gigantisch blok uitbreidingsgeheugen en sluiten aan bij typische SSD-blokgroottes.

Uitbreiding van RISC-V: De Vector Processing Engine (VPE)

XCENA maakt gebruik van de uitbreidbaarheid van RISC-V om een aangepaste Vector Processing Engine (VPE) op subsystem-niveau te implementeren. Elke RISC-V-core krijgt een VPE-opdrachtwachtrij en kan de VPE vragen om diverse vectoroperaties te versnellen. Waarschijnlijk gebruikt XCENA speciale instructies om berichten in de VPE-wachtrijen te plaatsen en behandelt de code dit als een gigantische gedeelde coprocessor.

De VPE ondersteunt FP32 en FP16 en levert ongeveer 3 TFLOPS aan dot product doorvoer over de gehele chip. Indien de VPE's op 1,1 GHz draaien, kan elke VPE 128 FLOPS per cyclus volhouden. Opvallend is dat de VPE's geen integer-operaties lijken te versnellen; XCENA verwacht waarschijnlijk dat deze direct op de RISC-V-cores worden uitgevoerd. 3072 RISC-V-cores op 1,1 GHz zouden ongeveer 3T integer-operaties per seconde behalen als elke core één operatie per cyclus voltooit. Een andere curiositeit is dat de API van XCENA de VPU ontsluit via ingebouwde functies die een foutcode teruggeven. Code moet expliciet controleren op foutcondities zoals overflow en ongeldige toegangen, wat suggereert dat VPU-instructies geen exceptions triggeren.

SSD's als geheugen ("Infinite Memory")

De MX1 kan SSD's hosten, die aan de host worden gepresenteerd als CXL-geheugen. XCENA noemt dit "Infinite Memory". De MX1 kan SSD's in RAID hebben en beschikt over een matchende bandbreedte op zowel de downstream PCIe- als de upstream PCIe/CXL-links. Theoretisch kan hij dus zijn volledige bandbreedte naar de host verzadigen met alleen SSD's.

Omdat SSD's echter een hoge latentie hebben vergeleken met DRAM, verzacht de MX1 dit door het gekoppelde DDR5 te gebruiken als cache voor de SSD-inhoud. Caching werkt met pagina's van 64 KB, met een on-chip map cache van 1024 vermeldingen. De map cache werkt als een TLB en houdt bij welke DRAM-pagina's zijn gekoppeld aan SSD-gebaseerde adressen. Als een toegang in de map cache mist, veroorzaakt dit een page fault die wordt afgehandeld door firmware op de RISC-V-cores van de MX1. De firmware haalt de data van de SSD en werkt de mapping bij. (Er is hier een onduidelijkheid in de documentatie: een map cache van 1024 vermeldingen dekt slechts 64 MB bij pagina's van 64 KB, maar XCENA suggereert dat de cache standaard op 16 GB staat en aanpasbaar is in stappen van 16 MB).

Om het gekoppelde DDR5 verder te benutten, kunnen gebruikers een "pinned prefix" configureren, waarbij SSD-gebaseerde adressen vastgepind worden aan het DRAM. De grootte van deze regio kan in stappen van 16 MB worden geconfigureerd. Omdat een prefix impliceert dat het gepinde geheugen een aaneengesloten adresruimte moet beslaan, is dit minder flexibel dan caching op paginaniveau. Een pinned prefix is daarom het best geschikt voor het vasthouden van een veelgebruikte buffer in het DRAM.

Daarnaast kan de MX1 worden ingesteld om te prefetchen van de SSD. Prefetching helpt om de IO-paden bezet te houden en data-fetches te overlappen met de uitvoering van berekeningen.

Conclusie en perspectief

Zowel de MX1 als de LPDDR5X-PIM plaatsen berekeningen dicht bij het geheugen om hoge interne geheugenbandbreedte te benutten die niet toegankelijk is via de host-interface. De MX1 biedt een overtuigender scenario dan de LPDDR5X-PIM, omdat hij kan fungeren als een accelerator met eigen onboard-geheugen. Software hoeft niet om te gaan met de complexiteit van PIM-moduswisselingen, en het gebruik van de rekenkracht van de MX1 blokkeert geen geheugentoegangen van andere threads.

Het werken met caches zou ook eenvoudiger moeten zijn. Type 3 CXL-apparaten (CXL.mem) kunnen snoops gebruiken om host-cachelijnen ongeldig te maken (back-invalidate), waardoor het apparaat resultaten zichtbaar kan maken zonder geheugenregio's oncachebaar te maken. Samsung geeft aan dat het apparaat CXL-geheugensemantiek kan gebruiken om zijn geheugen te delen over CPU's en GPU's.

Wat betreft de pure rekenkracht biedt de MX1 niet veel doorvoer. Ter vergelijking: een Nvidia GeForce GTX 1080 met vergelijkbare onboard geheugenbandbreedte heeft 8,8 TFLOPS aan FP32-compute, tegenover de 3 TFLOPS van de MX1. Maar ruwe doorvoer is hier niet het hoofdpunt. De MX1 biedt een manier om de nadelen van geheugenuitbreiding te verzachten. Berekeningen aan de MX1-zijde vermijden de beperkte host-interface en de energie-overhead van het doorkruisen van de CXL-link. Een hypothetische accelerator met 8,8 TFLOPS zou beperkt worden tot slechts 64 GFLOPS als hij voor elke FLOP één byte over CXL zou moeten laden. De MX1 zou in hetzelfde scenario meer dan 200 GFLOPS kunnen halen, zelfs bij cache-misses.

De aanpak van near-memory compute van de MX1 is veelbelovend. CXL-geheugenuitbreiders hebben vaak een hogere bandbreedte naar hun DRAM-pool dan wat de CXL-link kan verwerken. Een optie voor near-memory compute kan deze problemen oplossen zonder de nadelen van een implementatie onder een normale geheugencontroller, zoals bij de LPDDR5X-PIM.