A memory device designed to do more than add capacity

XCENA used the Hot Chips 2026 memory session to detail MX1, a device intended to change the role of expansion memory in servers. Rather than acting solely as additional capacity attached to a host processor, MX1 combines CXL memory expansion with programmable compute resources positioned alongside the memory.

The approach addresses a familiar issue in AI inference and large-scale analytics: useful data frequently has to travel between memory, CPUs and accelerators before relatively simple operations can be completed. That movement consumes bandwidth and energy, while also occupying host processing capacity. MX1 is built around the alternative of moving selected operations closer to the data, leaving CPUs and GPUs to concentrate on work for which they are better suited.

The timing is notable. AI infrastructure is increasing demand not only for accelerator performance but also for memory capacity, bandwidth and more efficient handling of large data sets. CXL, the coherent interconnect standard underlying MX1, is intended to make it possible for compatible systems to attach and manage memory resources more flexibly. The CXL 3.2 specification adds functions relevant to memory-device monitoring, management, security and tiering.

Hot Chips listed the MX1 presentation in its August 25 memory session, with speakers from XCENA and Samsung Electronics. The conference slot does not amount to product qualification, but it gives the company a technical venue to describe an architecture that sits between conventional CXL memory expansion and a dedicated accelerator.

Three layers in one device

XCENA describes MX1 as a CXL Type 3 device with three principal functions: DRAM expansion, SSD-backed capacity and near-memory computation.

First, the device is designed to provide up to 2 TB of DDR5 memory across four memory channels. It connects to the host through dual PCIe 6.0 x8 links and supports CXL 3.2. In a compatible server, this could provide a route to expand memory without increasing the number of CPU sockets or adding a complete new server node.

Second, the architecture incorporates what XCENA calls InfiniteMemory, which attaches SSD storage behind the device. Frequently used data pages are cached in DRAM, while colder data can remain on SSD. The aim is not to make flash behave identically to DRAM: storage latency remains materially higher. Instead, the design seeks to create a larger memory-accessible tier with software and hardware mechanisms that try to keep active data in faster memory.

Third, MX1 places more than 1,000 custom RISC-V cores close to its memory resources. These cores are organised into Memory Acceleration Units and paired with vector processing capability. XCENA says the vector engines offer around 3 TFLOPS of FP32/FP16 dot-product performance, aimed at work such as vector-search operations and KV-cache scoring.

This combination makes MX1 distinct from a passive memory expander. Its purpose is to execute suitably parallel, memory-bound kernels at the location where the data is held. Examples include filtering, aggregation, compression, decompression and preprocessing. These jobs can be costly when they require data to be fetched across an interconnect to a host CPU only to be written back after processing.

Performance claims require workload context

XCENA reported benchmark results across six data-processing kernels: compression, decompression, Parquet decoding, less-than filtering, LIKE filtering and aggregation. Against a host CPU accessing data over CXL, it said a single MX1 delivered up to 4.7 times higher throughput and up to 18.7 times better energy efficiency. Against the same host CPU processing data in local DDR5, the company reported gains of up to 2.0 times in throughput and 6.2 times in energy efficiency.

Those figures are potentially significant, but their limits are as important as their headline values. They are company-reported peak results across selected kernels, not a general measure of all AI or database workloads. The comparison also depends on the specific host configuration, NUMA placement, data sizes, implementation quality and the proportion of time a workload spends moving versus transforming data.

The architecture is most likely to benefit tasks with high data parallelism and modest control-flow complexity. It is less likely to displace CPUs for broad operating-system work or GPUs for large dense tensor computation. XCENA presents MX1 as a complement to those processors rather than a replacement, and that distinction is central to the product’s potential role.

Near-memory processing also introduces a software challenge. Offload only helps when the cost of dispatching work, managing data structures and synchronising results is lower than the data-movement cost it avoids. Applications therefore need kernels that map efficiently to MX1’s RISC-V cores and vector engines. XCENA says developers can use C, C++ or Rust through an LLVM-based toolchain, with its PXL runtime managing execution and shared virtual addressing. It is also developing higher-level integrations for analytics engines, vector search and wider AI-data frameworks.

CXL compatibility is the practical test

CXL is an important enabler, but device support by itself does not guarantee deployment. A system needs compatible processors, platform firmware, operating-system support and validation across memory-management, reliability and security functions. Data-centre operators will also assess how an expansion device behaves under faults, firmware updates, mixed workloads and multi-tenant conditions.

MX1’s published specifications address several of these concerns. XCENA lists DRAM error correction, Chipkill and multi-bit error detection, SSD RAID support, inline AES-XTS 256 encryption, hardware-assisted LZ4 decompression and CXL features including hot-page monitoring. Such functions indicate that the design is aimed at enterprise and hyperscale environments rather than experimental lab use.

Still, the difference between an architectural proof point and a deployed fleet can be substantial. Operators will need evidence of predictable tail latency, repeatable gains with their own data formats, dependable toolchains and manageable failure domains. The SSD-backed tier will require particularly careful policy decisions, because a poor placement decision can expose flash latency in an application path that expects DRAM-like responsiveness.

A step toward more specialised memory tiers

MX1 reflects a broader shift in server design. For decades, memory was largely a passive resource: capacity and bandwidth mattered, but computation happened elsewhere. Modern AI systems are making that separation more expensive. As model context, retrieval systems and intermediate data sets grow, the value of reducing unnecessary traffic rises alongside the value of adding raw compute.

XCENA’s proposition is to turn a CXL memory device into a specialised processing tier: one that expands capacity, connects to deeper SSD-backed storage and accelerates a defined set of data-local operations. If the company’s performance claims are reproduced in production environments, the result could be fewer host resources devoted to moving and preparing data.

The next evidence will come from product availability and customer validation. XCENA says it plans to begin mass production by the end of 2026 and targets initial customer revenue in 2027. The architecture is technically ambitious, but its commercial significance will depend on software maturity, server-platform compatibility and whether real workloads consistently benefit from putting computation nearer to memory.

Sources