DARTH-PUM: A Hybrid Processing-Using-Memory Architecture

Analog processing-using-memory computes matrix-vector multiplies right inside a memory array very efficiently, but it cannot do the other operations real kernels need — so it bolts on fixed-function CMOS logic and ends up stuck as a machine-learning inference accelerator; this paper (UIUC and Sandia — Ryan Wong, Ben Feinberg, Saugata Ghose) instead puts analog PUM and digital (Boolean) PUM on the same ReRAM chip, using digital PUM's general-purpose logic to handle every non-matrix operation in memory, and with the coordinating hardware, an easy programming interface, and flexible data widths that makes practical, it runs AES, CNNs, and LLMs entirely in memory at 59.4, 14.8, and 40.8 times the speed of an analog-plus-CPU baseline.

The argument in one glance

Problem

Computing inside memory is great at matrix multiply, but a real kernel needs more than that

Moving data between the CPU and memory costs far more time and energy than the arithmetic itself, so a tempting idea is to compute right inside the memory array. Analog processing-using-memory does exactly this for one operation: by driving voltages onto a grid of memory devices and letting Ohm and Kirchhoff physics sum the currents, it performs a whole matrix-vector multiply in one shot, cheaply and fast. The trouble is that almost no useful kernel is only matrix-vector multiply. A neural network also needs activations and pooling; a transformer needs softmax, square root, and layer normalization; AES encryption needs byte substitutions and shifts. Analog PUM physically cannot do any of these non-matrix operations, so the elegant in-memory multiply is surrounded by work it cannot touch.
What people did

Bolt fixed-function CMOS logic onto the array, or ship the rest back to the CPU

To finish the kernel while staying efficient, analog PUM architectures graft specialized CMOS circuits — custom activation units, special-function units — directly onto the memory chip, or they send the non-matrix work back to the host CPU. Either way the array gets to keep doing the multiplies it is good at, and the rest is handled by something purpose-built for a particular application.
Why it fell short

That locks the chip to one application domain, mostly ML inference

Wedging specialized CMOS logic in among dense memory arrays is genuinely hard, and every extra function unit costs area and design effort. Because the added logic is application-specific, the resulting chip only accelerates the application it was built for, which is why analog PUM has largely stayed a machine-learning inference accelerator. Offloading to the CPU instead reintroduces exactly the data-movement cost that in-memory computing was meant to avoid. Digital (Boolean) PUM can compute anything, but it uses completely different devices, voltages, and peripheral circuits, so the two styles had never been fused into one general chip.
This paper's idea

Put analog and digital PUM on the same chip and let digital do everything analog cannot

DARTH-PUM builds a hybrid tile that holds both an analog compute element for matrix-vector multiply and a digital (Boolean) compute element for everything else, on the same ReRAM substrate. The generality of digital PUM replaces the application-specific CMOS units entirely: activations, softmax, byte substitutions, and shift-and-add post-processing all run in the neighboring digital arrays, so a kernel executes fully in memory with no offload and no special-function hardware. To make this practical the paper adds coordinating hardware that rate-matches the two element types, an arbiter and instruction-injection unit, error compensation, an easy programming interface, and flexible operand widths. The same chip then runs AES, CNNs, and LLMs at 59.4, 14.8, and 40.8 times an analog-plus-CPU baseline.

Why this problem is worth solving

The reason in-memory computing is attractive is also the reason its two flavors were stuck apart.

Processing-using-memory computes by exploiting the electrical characteristics of the memory devices themselves, rather than reading data out to a separate compute unit. It comes in two very different flavors. Analog PUM stores multiple bits per device as a resistance, drives the input as voltages onto the array, and lets Ohm’s Law do the per-device multiply and Kirchhoff’s Current Law sum the results along a shared wire — so an entire matrix-vector multiply happens in one parallel step, which is fast and energy-efficient. But it is analog, so it is approximate and noisy, it needs power-hungry analog-to-digital and digital-to-analog converters at its edges, and it can only do that one multiply-accumulate operation. Digital, or Boolean, PUM instead stores a single bit per device and realizes a Boolean logic gate (a NOR, an AND) directly between memory cells; by chaining these gates sequentially it can compute anything a CPU can, with far fewer errors, but a single arithmetic operation expands into many slow bitwise steps. The two use different devices, different voltages, and different peripheral circuits, which is exactly why fusing them onto one chip had not been done, and why analog PUM kept reaching for bespoke CMOS instead.

The gap matters because it is what keeps a genuinely efficient technology narrow.

To make an analog PUM chip finish a real kernel, designers add domain-specific fixed-function hardware next to the arrays — a special-function unit for a neural network’s activation, another for its pooling, and so on. Each such unit is CMOS logic that must be squeezed in among the dense memory arrays, which is difficult to lay out, and each is built for one operation in one application. The consequence is a chip that is superb at, say, convolutional-network inference and useless for anything else, because changing the application would require redesigning the special-function hardware. This is the trap: analog PUM’s efficiency is real, but the only way anyone knew to complete a kernel tied the whole chip to a single domain, so the field’s most energy-efficient compute primitive stayed boxed into machine-learning inference and a few close relatives. Breaking out requires a way to perform the arbitrary non-matrix operations without inventing new application-specific silicon each time — which is precisely the general-purpose capability that digital PUM already has, if only it could live on the same chip as the analog arrays.

What people did before, and where it broke

Analog PUM with special-function units. Add custom CMOS blocks next to the memory arrays to compute the activations, poolings, and other non-matrix operations a kernel needs. Where it broke. The units are application-specific and physically hard to integrate among dense arrays, so the chip accelerates only the one application it was designed for and cannot adapt to a new kernel without a hardware redesign.
Analog PUM that offloads non-matrix work to the CPU. Keep the array doing matrix-vector multiplies and send everything else back to the host processor. Where it broke. Shipping data to the CPU and back reintroduces exactly the data-movement latency and energy that in-memory computing exists to eliminate; the paper measures that the non-matrix steps dominate CPU time for a kernel like AES.
Pure digital (Boolean) PUM. Use Boolean-complete in-memory logic to compute the whole kernel generally, with high error resilience. Where it broke. A single arithmetic operation decomposes into tens of sequential bitwise steps, so digital PUM is far slower than analog on the matrix-heavy parts of a workload, where analog’s one-shot multiply is enormously more efficient.
Application-specialized analog-plus-digital designs. Prior work paired analog PUM with a bit of digital PUM tailored to one application (hyper-dimensional computing, transformers). Where it broke. These use digital PUM only as bespoke support for a specific kernel; they do not harness its general-purpose nature, so the design still does not extend to new applications without redoing the specialization.
The gap. No architecture integrated analog and digital PUM into one general chip where the digital side supplies every non-matrix operation for any kernel, with the coordinating hardware, programming interface, and flexible data widths needed to make such a hybrid actually usable and efficient.

How DARTH-PUM works

Fusing an analog multiply engine and a digital logic engine into one in-memory tile

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Let the general-purpose flavor of in-memory computing absorb everything the specialized flavor cannot do. The whole design rests on a reframing: the problem was never that analog PUM lacks a way to do activations or softmax, but that the field kept solving it with bespoke CMOS units instead of the general-purpose in-memory logic that already existed. Digital PUM is Boolean-complete — chain its in-memory gates and you can compute anything — so DARTH-PUM uses it as the universal helper for the analog arrays, letting one digital element replace an open-ended zoo of application-specific special-function units. That single substitution is what turns analog PUM from a fixed ML-inference accelerator into a general-purpose in-memory computer, because now a new kernel needs new software, not new silicon. Extending an analog compute substrate to cover operations it was never natively meant for, rather than accepting its narrow native repertoire, is the same ambition the novel analog compute-paradigm work covered elsewhere on this site pursues, pushing analog hardware past the small set of functions it directly implements.

The hard part is the seam, so most of the architecture is coordination. Putting two compute styles on one chip is easy to say and hard to build, because analog and digital PUM run at wildly different speeds and expect different data formats. A matrix-vector multiply finishes in one parallel analog step but takes hundreds of cycles to digitize; a Boolean operation is quick but a single ADD explodes into tens of them. Left uncoordinated, the fast element starves or floods the slow one, and their instructions collide. So DARTH-PUM spends its design budget on the seam: an interface of shift units and converters sized to rate-match the analog output against the digital write bandwidth, an arbiter that keeps a long analog operation atomic so digital work does not interleave into the middle of it, and an instruction-injection unit that manages the micro-operation expansion in hardware. Treating a memory array as something that must fluidly switch between two operating modes and building the control to arbitrate that switch is the same duality the dual-mode compute-in-memory work covered elsewhere on this site is organized around, where a cell must serve as both storage and compute and the system decides which role it plays when.

Make it programmable, or it is just another one-off accelerator. A hybrid chip that only an author can program would not escape the specialization trap it is trying to break, so DARTH-PUM exposes a real software stack. Its library offers matrix-centric, application-agnostic commands — allocate a matrix into the analog arrays, run a multiply, apply an activation in the digital arrays — that let an ordinary programmer map a kernel without knowing the circuit, while a full hybrid instruction set and hardware-centric commands let an expert control precision, allocation, and data placement to squeeze out performance. Crucially, the messy detail of turning one high-level instruction into its many in-memory bitwise steps is handled by a per-tile injection unit in hardware rather than dumped on the compiler or the front end, which is what keeps the general interface from becoming a bottleneck. Providing a proper compilation and programming path so that an in-memory accelerator can be targeted by many applications, instead of hand-mapped to one, is the same enabling move the multi-level compute-in-memory compilation-stack work covered elsewhere on this site makes, turning a raw in-memory fabric into something software can actually aim at.

Following an AES encryption through DARTH-PUM

Encrypting a block fully in memory by splitting matrix and non-matrix work

A trace, drawn from the paper's AES mapping, of how DARTH-PUM runs a kernel that is mostly operations analog PUM cannot perform.

Step 1 of 5

A kernel that is mostly not matrix multiply

AES encrypts a 16-byte block through rounds of four steps: SubBytes, ShiftRows, MixColumns, and AddRoundKey. Only MixColumns is a matrix-vector multiply; the other three are byte substitutions, row shifts, and key additions that analog PUM cannot do. On a CPU these non-matrix steps dominate the time, which is exactly why an analog-plus-CPU design is slow here.

The paper finds via gem5 simulation that the non-matrix operations consume most of the CPU work in AES, motivating keeping them in memory.

Why it works

General-purpose digital PUM replaces an open-ended set of special-function units. Analog PUM needs bespoke CMOS for every non-matrix operation → but a Boolean-complete digital element can compute all of them in memory → so one general helper covers every application and a new kernel needs only new software, not new silicon.
Keeping everything on-chip removes the offload penalty. Sending non-matrix work to the CPU reintroduces the data movement in-memory computing exists to avoid → but the digital element finishes those operations in the same tile → so kernels like AES, where non-matrix steps dominate, run without shuttling state to the host.
Rate-matching the seam keeps the fast element from starving the slow one. A one-shot analog multiply and a many-step Boolean sequence run at very different speeds → but sizing the converter-and-shift interface to match analog output rate to digital write bandwidth balances them → so neither element idles waiting on the other, which is where naive hybrids lose their gains.
Hardware micro-op expansion keeps the general interface from stalling. A single high-level ADD becomes tens of sequential Boolean operations → but a per-tile injection unit expands it in hardware instead of through the front end → so the easy programming interface does not create front-end stalls or contention for the digital pipelines.
A simple digital logic family is enough, so the chip stays area-efficient. Supporting many Boolean operators would inflate peripheral area and complexity → but the paper finds a single primitive (OSCAR NOR) gets within 3.2 percent of an ideal logic family → so the hybrid tile is compact, which is what lets it beat even application-specific accelerators in iso-area comparisons.

What it costs (trade-offs and scope)

Analog PUM is still approximate, and the paper must compensate. The analog element inherits noise, device non-linearity, and drift, capping effective precision at roughly 6 to 12 bits and requiring an error-compensation scheme (differential cell pairs, scale factors, bit-slicing) to get correct results; accuracy is exposed to the programmer as a tunable target that trades bits-per-cell against how many tiles a computation needs.
The seam is where the design complexity lives. Much of the architecture — the arbiter, the instruction-injection unit, the rate-matched converter interface, the atomicity rules that stop digital instructions from interleaving into a long analog multiply — exists solely to coordinate two mismatched compute styles, so the benefit depends on this coordination hardware being correct and well-sized, not just on the two elements individually.
Not every part of a kernel maps cleanly to analog. In the LLM encoder, the attention matrices are updated dynamically, and analog arrays are slow and costly to reprogram, so the paper runs attention in the digital element and reserves the analog element for the feed-forward network; which operations belong on which element is an application-mapping decision, not automatic.
Results are from simulation, iso-area, against chosen baselines. The speedups and energy numbers come from a modified circuit-and-architecture simulator at one gigahertz, compared iso-area to an analog-plus-CPU baseline (and to pure-digital and application-specific accelerators); they are strong, but they are modeled rather than measured on fabricated silicon, and the headline figures are best cases across three specific workloads.
Digital PUM’s slowness still bounds the non-matrix parts. Boolean operations run sequentially, so an operation that expands into many bitwise steps is intrinsically slower per-op than dedicated logic; DARTH-PUM wins overall by avoiding data movement and special-function area, not because its digital element is individually faster than a custom unit at any single function.

The evaluation

Executing full matrix-based kernels in or near memory

Property	Analog PUM + CPU	Pure digital PUM	DARTH-PUM (hybrid)
Matrix-vector multiply
Non-matrix operations
Application-specific hardware
Programmable across domains
Reported result vs baseline

A comparison drawn from the paper. DARTH-PUM is evaluated in simulation, iso-area, against an analog-plus-CPU Baseline, a pure DigitalPUM configuration, and application-specific accelerators (AppAccel); the speedups and energy reductions are for AES, convolutional neural networks, and large language models respectively.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

The full paper text was available (the authors’ arXiv version, 2602.16075), so this account of the mechanism — the analog and digital PUM primitives, the Hybrid Compute Tile with its Analog and Digital Compute Elements, the rate-matched analog-digital interface, the arbiter and instruction-injection unit, the error-compensation scheme, the ISA-and-library programming interface, and the AES, CNN, and LLM mappings — follows the paper’s own description. The headline numbers are the paper’s reported results: 59.4, 14.8, and 40.8 times speedups and 39.6, 51.2, and 110.7 times energy reductions over an analog-plus-CPU baseline for AES, CNNs, and LLMs, with an average 31.4 times throughput improvement, all measured iso-area in a modified circuit-and-architecture simulator rather than on fabricated hardware. The comparison baselines (a specific analog accelerator plus a state-of-the-art CPU, a pure-digital PUM, and application-specific accelerators) and the exact per-kernel breakdowns should be read from the paper itself; the figures are best cases across three chosen workloads.

Background

Why computing inside memory is worth this much effort

It is worth remembering what all of this is fighting. In a conventional system, the arithmetic a program does is cheap, but fetching its operands from memory and writing results back is not: the latency and energy of moving data across the chip are orders of magnitude larger than the compute itself, and for data-heavy workloads — machine learning, databases, scientific computing — that movement dominates the bill. Processing-using-memory attacks this at the root by doing the computation where the data already lives, inside the memory array, so the operands never make the expensive trip. That is why the field is willing to wrestle with analog noise and Boolean-logic slowness at all: the prize is eliminating the data movement, not merely speeding up the math. DARTH-PUM’s whole reason for fusing analog and digital PUM is to keep an entire kernel on the memory side of that divide, non-matrix operations included, so nothing has to be shipped back to a CPU. This drive to turn the memory itself into the compute engine and thereby erase the data-transfer tax is the same premise the compiler-for-in-memory-accelerator work covered elsewhere on this site is built on, treating the memory array as a first-class place to run computation rather than a passive store the processor reaches into.

If you remember only three things

1. Analog processing-using-memory does matrix-vector multiply extremely efficiently inside a memory array, but it physically cannot perform the non-matrix operations real kernels need (activations, softmax, byte substitutions), so it bolts on application-specific CMOS special-function units or offloads to the CPU — which ties the chip to one domain (mostly ML inference) and reintroduces data movement; digital (Boolean) PUM is general-purpose but slow on matrix work and uses entirely different hardware, so the two had never been fused.
2. DARTH-PUM puts both on the same ReRAM chip as a Hybrid Compute Tile pairing an Analog Compute Element (matrix-vector multiply) with a Digital Compute Element (Boolean logic), and uses digital PUM's generality to perform every operation analog cannot — eliminating special-function units and CPU offload. It makes the hybrid practical with rate-matching interface hardware, an arbiter and instruction-injection unit that keep long analog operations atomic, error compensation, flexible operand widths, and an ISA-plus-library programming interface; a single simple Boolean primitive (OSCAR NOR) gets within 3.2 percent of an ideal logic family, keeping the tile area-efficient.
3. Running whole kernels in memory, DARTH-PUM reports 59.4, 14.8, and 40.8 times speedups and 39.6, 51.2, and 110.7 times energy reductions over an analog-plus-CPU baseline for AES, CNNs, and LLMs (average 31.4 times throughput), and even beats application-specific accelerators in iso-area comparisons thanks to its compact hybrid tiles. Results are from a circuit-and-architecture simulator, not fabricated silicon, and the analog element remains approximate, needing an explicit error-compensation scheme.

Check yourself

Check your understanding

1. Why has analog processing-using-memory largely been stuck as a machine-learning inference accelerator?
2. What is the central idea of DARTH-PUM?
3. Why does most of the DARTH-PUM architecture focus on coordinating the two elements rather than on the elements themselves?
4. What are the main results of DARTH-PUM, and what should a reader keep in mind about them?

Sources

The paper is “DARTH-PUM: A Hybrid Processing-Using-Memory Architecture” by Ryan Wong and Saugata Ghose (University of Illinois Urbana-Champaign) and Ben Feinberg (Sandia National Laboratories), published at ASPLOS 2026, DOI 10.1145/3779212.3790151. DARTH-PUM stands for Digital-Analog Resistive Tiles for Hybrid Processing-Using-Memory.

This explainer is based on the paper’s full text, obtained from the authors’ arXiv preprint (arXiv:2602.16075). The account of the mechanism — analog PUM (matrix-vector multiply via Ohm’s and Kirchhoff’s laws, ADCs and DACs, bit-slicing, and analog non-idealities) and digital Boolean PUM (in-memory logic primitives such as OSCAR NOR, bit-pipelining), the Hybrid Compute Tile with its Analog and Digital Compute Elements and front end, the four coordinating additions (the rate-matched analog-digital interface of shift units and ADCs, the analog-digital arbiter and instruction-injection unit, the error-compensation scheme, and the ISA-plus-library software interface with flexible data widths), and the application mappings for AES encryption, convolutional neural networks, and LLM encoders — follows the paper’s own description. The reported results cited here are the paper’s own: speedups of 59.4, 14.8, and 40.8 times and energy reductions of 39.6, 51.2, and 110.7 times over an analog-plus-CPU baseline for AES, CNNs, and LLMs, an average 31.4 times throughput improvement over that baseline, and a finding that a single Boolean primitive comes within 3.2 percent of an ideal logic family. All results are from a modified circuit-and-architecture simulator with iso-area comparisons; exact per-kernel numbers, the baseline configurations, and circuit details should be read from the paper itself.