Hot Chips 2026: Samsung’s Processing-in-Memory (PIM)

De architectuur van LPDDR5X-PIM

DRAM-chips zijn intern verdeeld in banks, die elk beschikken over hun eigen lees- en schrijflogica. Tijdens een normale DRAM-toegang selecteert de geheugencontroller een bank, activeert een rij daarbinnen en grijpt vervolgens op de data via column access strobe (CAS) commando's. De bandbreedte wordt hierbij beperkt door de externe DRAM-interface van de chip. Zelfs als de geheugencontroller alle banks gelijktijdig zou kunnen activeren, zou deze niet in staat zijn om de volledige bandbreedte te benutten die over alle banks beschikbaar is.

Samsung’s LPDDR5X-PIM lijkt op een normale LPDDR5X-9600 chip met 16 banks, maar plaatst bij elke bank een PIM-blok. Deze PIM-blokken hebben toegang tot hun gekoppelde DRAM-bank zonder beperkt te worden door de externe bus van de chip. Samen kunnen ze de interne bandbreedte van de chip over alle 16 banks benutten, wat neerkomt op 614 GB/s. Ter vergelijking: reguliere DRAM-toegang kan maximaal twee banks parallel aanspreken en haalt een maximum van 76,8 GB/s.

Technische specificaties van het PIM-blok

De PIM-blokken bestaan intern uit een MAC-boom met daaromheen registerbestanden en besturingslogica:

• Instructie-registerbestand: 1024-bit, houdt tot 64 16-bit instructies vast.
• Source-registerbestand: 4 kbit, bedoeld voor activatievectoren en levert één source-operand voor de MAC-array.
• DRAM-blok: Levert het tweede operand (de modelgewichten die door software in het DRAM worden geladen).
• Scale-register: 2 kbit, waarmee modelgewichten kunnen worden geschaald vóór de MAC-berekening.

De MAC-array van het PIM-blok ondersteunt diverse precisieformaten. Gegevens uit de presentatie van Samsung suggereren dat de MAC-array van elk PIM-blok vier INT8- of FP8-MAC-operaties per dataklok kan ondersteunen, of acht per cyclus als de double data rate niet wordt meegeteld. Voor 4-bit inputgewichten verdubbelt de doorvoer, waardoor de rekenkracht van het gehele pakket op 2,4 TOPS komt.

Hoewel dit getal niet erg hoog is, zal een implementatie met veel LPDDR5X-chips een hogere geaggregeerde doorvoer hebben. Acht LPDDR5X-chips zouden samen bijvoorbeeld 9,6 INT8 TOPS hebben, wat ongeveer gelijk is aan de NPU in Intel’s Meteor Lake. Dit zou echter een dure configuratie zijn, aangezien acht 16 GB LPDDR5X-chips overeenkomen met 128 GB systeemgeheugen.

Compute via standaard DDR-commando's

Een belangrijk kenmerk van LPDDR5X-PIM is dat het binnen het standaard LPDDR5X-protocol blijft, terwijl het rekencapaciteiten ontsluit die geen deel uitmaken van de geheugenstandaard. Samsung bereikt dit door speciale rijadressen te reserveren, die fungeren als een soort MMIO-adressen.

Elk kanaal heeft een paar vooraf gedefinieerde rijen voor moduscontrole:

• Single-bank mode: De reguliere modus.
• Multi-bank mode: Past commando's toe over alle 16 banks om de interne bandbreedte van de chip te benutten.

Speciale per-bank rijen veranderen hoe lees- en schrijfcommando's zich gedragen. Het activeren van een van deze speciale rijen zorgt ervoor dat lees- en schrijfcommando's toegang krijgen tot PIM-registers in plaats van de reguliere inhoud van de DRAM-bank (PIM Registers Activated mode).

Workflow in de praktijk

Samsung voorziet een ML-gebruiksscenario waarbij:

1. Software modelgewichten in het DRAM laadt terwijl de chip in de normale single-bank mode staat.
2. De software schakelt over naar multi-bank mode en activeert de PIM Registers Activated mode.
3. Code activatiewaarden in de PIM-sourceregisters schrijft, schaalfactoren in de PIM-scaleregisters instelt en een operatie specificeert in de PIM-instructieregisters.

Omdat de chip in multi-bank mode staat, wordt elke schrijfactie naar een PIM-register uitgezonden naar alle 16 banks. PIM-compute werkt dus als een zeer beperkte SIMD-processor, waarbij de operatie, de schaalfactor en één source-operand voor alle banks gelijk zijn. Samsung staat het schrijven van PIM-registers in single-bank mode toe, maar dit is uitsluitend bedoeld voor debugging. Gezien elk DRAM-pakket 256 bits is (BL=16), vereist het vullen van elk sourceregister 16 schrijfcommando's. Dit één voor één per bank te doen over alle 16 banks zou 256 schrijfcommando's betekenen, waardoor de bandbreedte van de host naar het PIM-register de beperkende factor wordt.

Nadat de PIM-registers zijn voorbereid, schakelt de software terug naar multi-bank mode en geeft leescommando's af. In plaats van DRAM-inhoud te lezen, initiëren deze commando's berekeningen waarvan de resultaten worden verzameld in PIM-vectorregisterbestanden (VRF). Vervolgens geven schrijfcommando's de PIM-blokken de opdracht om de VRF-inhoud terug te schrijven naar de DRAM-banks.

Address Align Mode (AAM)

PIM moet omgaan met de herordening (reordering) die een normale geheugencontroller kan uitvoeren. Normaal gesproken zijn de instructieregisters zo ingesteld dat instructies sequentieel toegang krijgen tot elk sourceregister-element. Dit werkt niet als de geheugencontroller de toegangen herordent. Samsung lost dit op met een Address Align Mode (AAM), waardoor elke instructie zijn sourceregister-index afleidt uit het kolomadres dat wordt benaderd.

Wanneer de host klaar is met de in-memory compute en de resultaten wil lezen, schakelt hij de DRAM-chip terug naar single-bank mode. Vanaf dat moment werken reguliere DRAM-lees- en schrijfacties weer normaal.

Software-uitdagingen

Hoewel Samsung intern enorme prestatiewinsten heeft behaald met LPDDR5X-PIM vergeleken met standaard LPDDR5X, zijn de softwarematige uitdagingen aanzienlijk. Omdat PIM-modi de betekenis van DRAM-toegangscommando's veranderen, kan software PIM niet tegelijkertijd met reguliere geheugentoegangen gebruiken.

Dit geldt zelfs voor verschillende threads, omdat geheugencontrollers en DRAM-chips niet weten voor welke thread een toegang is bedoeld. Als een non-PIM thread leest uit het geheugen terwijl een andere thread PIM gebruikt, kan de eerste thread onbedoeld een berekening triggeren en incorrecte resultaten in de PIM VRF's veroorzaken. Een schrijfactie van een non-PIM thread zou ertoe kunnen leiden dat PIM-blokken VRF-data naar het verkeerde adres schrijven.

Isolatie en multitasking

Samsung lost dit op door de host een PIM-regio in het geheugen te laten isoleren. In een typisch systeem is dit lastig zonder de geheugenbandbreedte en PIM-prestaties te compromitteren. Hardware interleave-t adressen normaal gesproken over kanalen om de bandbreedte optimaal te benutten. Aangezien PIM per-kanaal rijen gebruikt om de modus te wijzigen, is het uitschakelen van interleaving en het aanwijzen van geheugenkanalen als "PIM-only" de enige redelijke manier om een PIM-regio te creëren. Dit betekent echter dat non-PIM applicaties geen gebruik kunnen maken van de bandbreedte van de gereserveerde kanalen, en PIM-code de bandbreedte en rekenkracht van de non-PIM kanalen mist.

Multitasking-problemen blijven bestaan, zelfs na isolatie:

• Locks: Applicaties die PIM in een multithreaded omgeving willen gebruiken, moeten toegang tot de PIM-regio beschermen met locks.
• OS-beheer: In een modern besturingssysteem kunnen meerdere processen PIM proberen te gebruiken zonder van elkaar op de hoogte te zijn. De enige oplossing lijkt het uitvoeren van PIM-code terwijl alle andere threads worden geblokkeerd en interrupts worden uitgeschakeld.
• Context switches: Het onderbreken van een PIM-thread zou betekenen dat het geheugenkanaal uit PIM-modus moet worden gehaald en de PIM-status (instructies, source, scale en vector register files over elke bank) moet worden opgeslagen.

Problemen met caches en Out-of-Order Executie

PIM-compute doorbreekt de verwachtingen van een geheugensubsysteem over DRAM-gedrag, omdat DRAM geheugenwaarden kan genereren waar de cache-hiërarchie geen kennis van heeft. Caches kunnen PIM-gedrag bovendien verstoren door toegangen te absorberen die bedoeld waren om PIM-operaties te triggeren. Daarom adviseert Samsung om PIM-geheugen als uncacheable (niet-cachebaar) in te stellen. Dit is problematisch, omdat moderne CPU's en GPU's zwaar leunen op caching om DRAM-latentie te verminderen; prestaties op uncacheable geheugen zullen extreem traag zijn.

Daarnaast werken PIM-leesacties als MMIO-toegangen: ze veroorzaken berekeningen die de PIM VRF-waarden beïnvloeden, in plaats van alleen data op te halen. Dit botst met moderne CPU-optimalisaties:

• Speculatieve executie: Branch prediction laat CPU's instructies uitvoeren voordat zeker is of deze daadwerkelijk uitgevoerd moeten worden.
• Prefetchers: Deze laden data in de cache voordat instructies erom vragen.

Bij normale loads is het geen probleem als data onnodig wordt geladen. Bij PIM is dat wel zo, omdat een leesactie een berekening triggert die de VRF-inhoud wijzigt. Het werken met een PIM-regio zal dus waarschijnlijk betekenen dat geheugentoegang zowel non-cachebaar als non-speculatief moet zijn, wat de prestaties van een CPU ernstig zal beperken.

Algemene uitdagingen van In-Memory Compute

Naast de modus-problemen zijn er overkoepelende uitdagingen voor software. Elk PIM-blok heeft alleen snelle toegang tot zijn lokaal gekoppelde DRAM-bank. Alle andere inputdata moet via de relatief beperkte externe interface van de DRAM-chip binnenkomen. PIM-blokken kunnen niet direct data met elkaar uitwisselen; de host moet data verplaatsen via reguliere DRAM-lees- en schrijfacties als een PIM-blok resultaten van een ander blok nodig heeft.

Conclusie en toekomstvisie

Samsung’s LPDDR5X-PIM kan theoretisch in elke server, desktop, laptop of mobiel apparaat worden geplaatst dankzij de compatibiliteit met standaard geheugencontrollers. Dat betekent echter niet dat het eenvoudig is om te gebruiken binnen huidige hardware- en softwareparadigma's. De moduswisselingen vormen een obstakel voor multitasking-besturingssystemen, en het feit dat leescommando's bijwerkingen hebben, breekt CPU-caching, prefetching en out-of-order executie.

Er is naar mijn mening geen eenvoudige manier om in-memory compute te gebruiken zonder wijzigingen in het geheugensubsysteem. De volgende hardwarematige aanpassingen zouden de adoptie door software kunnen vergemakkelijken:

1. Uitbreiding van de DRAM-interface: Voeg een set specifieke compute-commando's toe om de complexiteit van moduswisselingen te vermijden.
2. Cache-coherentie via de geheugencontroller: Laat de geheugencontroller fungeren als een peer CPU-core. De controller kan read-for-ownership (RFO) verzoeken verzenden voor alle betrokken cache-lijnen, zodat gewijzigde data wordt teruggeschreven naar het DRAM voordat de in-memory compute begint. De controller houdt het eigendom van deze lijnen vast tot de operaties zijn voltooid.
3. Nieuwe CPU-instructies: Introduceer instructies (zoals een hypothetische rep macb) die multiply-accumulate operaties over een geheugenblok uitvoeren. De CPU kan dan zelf beslissen of de berekening in-memory plaatsvindt (indien ondersteund door het DRAM) of intern wordt uitgevoerd (als de data al in de cache staat).

Met deze wijzigingen zou software in-memory compute kunnen gebruiken vanuit een multitasking OS zonder geheugen te hoeven reserveren of parallellisme te verliezen door locks. Een transparante CPU-instructie voorkomt bovendien het probleem van hardware-specifieke binaries en maakt de code vooruitcompatibel met verschillende in-memory compute implementaties. De huidige softwarematige alternatieven — het reserveren van geheugenregio's, ze non-cachebaar maken en threads blokkeren — brengen simpelweg te veel compromissen met zich mee op het gebied van prestaties, capaciteit en responsiviteit.