Free Sample Episode

Leveraging a Passive MRAM Crossbar for Hardware-in-the-Loop and Continual learning

Today's article comes from the IEEE Journal on Exploratory Solid-State Computational Devices and Circuits. The authors are Drouhin et al., from Spin-ion Technologies, in France. In this paper they're exploring whether magnetic memory devices can act not just as storage, but as the physical substrate for neural-network computation.

DOI: 10.1109/JXCDC.2026.3702001

Book
Book
Download the Audio (Right-click, Save-As)

If you pick an engineer at random, and ask them to sketch the basic architecture of a computer, there's a very good chance they'll draw something like this

  • On one side they'll draw a rectangle called "memory".
  • On the other side they'll draw a rectangle called "processor" or "CPU".
  • Then they'll put a couple little arrows connecting the two.
  • And if they want to get really fancy, the CPU box will itself contain some smaller labeled boxes, representing the different components of the processor.

This basic blueprint is called the von Neumann architecture. It's the canonical example that they teach you in school, and force you to memorize. And for many years, this is how the vast majority of our laptops, desktops and servers worked. Why? Because it's a superb compromise: simple enough to build, flexible enough to reuse, and abstract enough to support many different kinds of software.

You see, underneath their user-facing differences, most programs actually ask the machine to do the same small set of primitive things: move values around, perform arithmetic, compare conditions, jump to another instruction, and repeat. So whereas dedicated circuitry would bake a task into the hardware, von Neumann architecture made those primitives programmable instead. This way, the hardware did not need to know whether it was running a spreadsheet, a database, a compiler, or a video game. It only needed to fetch the next instruction, execute it, and fetch the next one after that. That's what the classic diagram is actually showing. The 'memory' rectangle is where the program and its data live. The 'processor' rectangle is the machinery that knows how to carry out basic operations. And the arrows between them are the working relationship: the processor reads an instruction from memory, uses it to decide what operation to perform and what data to operate on, writes back a result if the instruction requires it, and then returns to memory for the next instruction. The layout is not incidental. It separates storage from execution on purpose, then lets the stored program drive the processor one step at a time.

But then, in the last few decades, all that began to change. The separation that made von Neumann architecture so flexible also created a bottleneck. Since memory and processing were separate, the machine had to spend more and more time and energy moving data back and forth between them. And for ordinary software, that tradeoff was usually worth it. But for workloads that repeat the same operations at enormous scale, the cost of that movement starts to dominate. So in industry after industry, engineers and manufacturers began to move away from purely general-purpose designs and toward more specialized, purpose-built architectures. In networking, we began to see packet-processing ASICs. In cryptography, security coprocessors and hardware encryption engines. In graphics processing, the rise of GPUs. In area after area, the same pattern has kept unfolding: once an industry matures enough to understand the shape of its computation, the participants start to build hardware better suited to that shape.

The field of Artificial Intelligence is no exception. It's just that that trend has been happening much more recently and much more quickly. In just the last few years alone we've seen a proliferation of chips and systems designed specifically and explicitly for this workload. Ones that move less data, perform massive numbers of parallel operations, and reduce the energy cost of training and inference. Tensor processing units, neural processing units, systolic arrays, wafer-scale engines, and of course GPUs, just to name a few. Each design carrying its own unique benefits and costs, and its own energy/performance tradeoffs.

Today's paper is an exploration of yet another one of these designs: the passive MRAM crossbar. In it, the authors are exploring whether magnetic memory devices can act not just as storage, but as the physical substrate for neural-network computation. On today's episode we'll walk through the basics of this physical setup, learn how the authors programmed it, and see what they found when they built a prototype and tested it on real classification tasks. Let's dive in.

First, let's make clear what problem the authors are actually trying to solve here. Neural networks, as a whole, are full of matrix operations. At each layer, the system takes a batch of input values, multiplies those values by stored weights, and adds the results together to produce the next set of activations. That "multiply-and-accumulate" operation is simple, but it happens so many times that the cost becomes enormous. On conventional hardware, the weights usually sit in memory, but the arithmetic happens in the processor. So the machine is constantly moving data from memory to compute, doing the math, and then moving the results back again. The goal of what we call "in-memory computing" is to reduce that movement by making the memory array itself participate in the computation. Instead of storing weights as abstract numbers that have to be fetched before they can be used, the hardware stores weights as physical electrical states, applies the inputs directly to the array, and lets the output currents represent the result of the calculation.

To understand why you might want to use a "passive MRAM crossbar" (specifically) for this, we'll need to wrap our heads around what this device actually is, and how it works. The easiest place to start is the word "crossbar". A crossbar is a grid of horizontal and vertical wires, crossing each other with a memory device sitting at each intersection. The rows carry input values. The columns collect output values. And every crossing point stores one weight connecting a particular input to a particular output. Why? Because a neural-network layer has that same basic shape: many inputs, many outputs, and a weighted connection between each input-output pair. In software, we represent that as a matrix of numbers. In a crossbar, that matrix becomes a physical grid. The input values become voltages on the rows, the weights become conductances at the intersections, and the output values emerge as currents summed along the columns. The hardware layout mirrors the computation the network needs to perform.

The "MRAM" part tells us what kind of memory device sits at those intersections. MRAM stands for magnetic random-access memory, and here the specific device is called a magnetic tunnel junction, or MTJ. An MTJ has two magnetic layers separated by a thin insulating barrier. One layer is fixed, and the other can be switched. When the two layers point in the same direction, the device has one resistance state. When they point in opposite directions, it has another resistance state. This way, the device can store information as magnetism, and that stored magnetic state shows up electrically as a higher or lower conductance. That is useful for machine learning because a neural-network weight also needs to be stored somewhere and then used during computation. Here the stored state of the MTJ is not just a bit sitting idle in memory. It becomes the physical value that controls how much current flows when an input voltage is applied.

The "passive" part is about how much circuitry is placed around each memory device. In an "active" memory array, each cell may have its own access transistor or selector circuitry to help isolate and control it. In a passive crossbar, the memory devices are placed more directly at the wire intersections. That can make the array denser and simpler, which is attractive if the long-term goal is to pack many neural-network weights into hardware. But it also creates a tradeoff. Since the cells are not individually isolated in the same way, current can take unintended paths through the grid, the wires themselves can affect the measurement, and programming one device without disturbing others becomes harder. So "passive" definitely does not mean easier. It just means the array is more compact and more physically direct. But also more dependent on whether the underlying device and measurement scheme are stable enough to preserve the intended computation.

Now put those pieces together. A "passive MRAM crossbar" is then a grid-shaped memory array, built from magnetic memory devices, with minimal per-cell control circuitry. And to use it as neural-network hardware, the inputs are applied as voltages along the rows. The weights are encoded in the conductance states of the MTJs. And the currents flowing down each column naturally add together. That column current is the hardware version of a weighted sum. This is why the architecture is interesting, and worth exploring. It doesn't merely store the network. It gives the network's most common operation a physical form. And this is especially true for binary neural networks. In a normal neural network, weights may be represented with many bits of precision. But in a binary neural network, the effective weights are reduced to simpler values (0/1, true/false etc). And since each MTJ has two stable magnetic resistance states, MRAM devices are naturally binary too. So the device physics and the model architecture line up unusually well. The model wants simple binary weights. The memory device naturally stores binary states. And the crossbar layout naturally performs the weighted summation. And that is the particular setup being used in this paper.

So what did the authors actually do? First, they trained a few small networks in software, then they programmed the resulting binary weights onto the MRAM devices. Then, they applied inputs as voltages, and measured the output currents from the columns. That let them test whether the crossbar could perform inference as an actual analog multiply-and-accumulate structure. But inference alone is the easy case: once the weights are fixed, the hardware just has to execute them. The harder question is whether the hardware can be part of the learning process too. That's where something called HIL comes in.

Now you've probably heard of HITL before (human in the loop), but that's not what we're talking about here. HIL is Hardware In the Loop, and it's fundamental to how the authors were able to train the network. In a normal training loop, the model updates its weights entirely in software. In this HIL setup, each update is followed by programming the new binary weights onto the actual crossbar. That is: after the software computes the next binary weight matrix, the system applies electrical programming pulses to the crossbar, switching selected cells between their parallel and antiparallel states so the array physically stores the updated weights.The modified hardware is then measured, and the measured conductance values are fed back into the next software training step. This way, the model is learning against the real physical device, and the training process can adapt to device variability, imperfect conductance values, and other hardware idiosyncrasies instead of assuming an ideal playing field.

So what were the results? Once the prototype was built, and the HIL process was complete, did they have a working neural-network substrate that could perform useful computation and adapt during training? Or just a fancy memory array? To find out they benchmarked their system in three stages.

  • First, they tested inference by comparing the crossbar's measured output currents against numerical simulations of the same network.
  • Then they tested classification accuracy on a few small tasks.
  • Finally, they ran many HIL training trials under different schemes, and compared single-device programming against differential programming and full-precision hidden weights against quantized hidden weights.

And in the end, the results were promising. For inference, the hardware closely matched the numerical MAC results and correctly classified all 30 samples in the experiment. For HIL training, the system reached high accuracy across repeated runs, especially when using full-precision hidden weights, with differential programming giving slightly more stable results than single programming. That being said, quantized hidden weights did reduce accuracy, especially in smaller single-programming setups, but the authors show that this can be improved by increasing the effective network size or device count. For continual learning, metaplasticity helped reduce catastrophic forgetting when the system learned a second task, but overall retention was limited by the very small crossbar and network size.

So, what can we learn from this paper?

  • Narrowly, that a small passive MRAM crossbar can physically support binary neural-network inference, hardware-in-the-loop training, and a simple form of continual learning.
  • But more broadly, that physical hardware does not have to be treated as a passive execution target after training is finished. The physical behavior of the device can be brought into the learning process itself. This is important because future AI accelerators will likely not be perfect mathematical abstractions. They will be real devices with variability, noise, constraints, and failure modes. Hardware-in-the-loop training is one way to make a system adapt to those realities.

Want to go deeper? Make sure you download the PDF. The authors include the device-level conductance and TMR measurements, the crossbar programming details, the classification task results, the quantized-weight comparisons, the metaplasticity experiments, and more.