By: Netlist
Introduction
Early server deployments proved the value of persistent memory but also exposed a key limitation: persistence was typically constrained to socket-attached form factors and platform-specific enablement. With Compute Express Link® (CXL®), persistence can move onto a standard, cache-coherent fabric, opening new design space for scalable, composable systems.
Figure 1. Persistent memory evolution: NVDIMM-N (DRAM + NAND + backup power) transitioning to CXL Type-3 persistent memory on the PCIe/CXL fabric.
A Brief History of NVDIMM-N
NVDIMM-N was an early practical form of persistent memory in mainstream servers. It paired standard DRAM with on-module NAND flash and an embedded energy source. On power loss, DRAM contents were copied to NAND; on reboot, they were restored—preserving memory state across failures.
Because it provided persistence via a memory interface (not a block device), NVDIMM-N naturally fit low-latency use cases such as write logging, metadata journaling, and fast restart for stateful services.
JEDEC Maturity: Persistence Needs More Than Non-Volatility
JEDEC standardization helped make NVDIMM-N interoperable by defining device management and the expected system behaviors around save/restore flows, health reporting, and metadata/label areas. The bigger lesson still applies in the CXL era: persistent memory must deliver deterministic behavior during both graceful shutdowns and surprise power loss, with clear firmware/OS coordination and robust RAS.
Figure 2. Requirements for deterministic persistence (save trigger, power hold-up, DRAM→NAND copy completion, restore before host access, health telemetry).
Why CXL Changes the Design Space
CXL extends PCIe with cache-coherent semantics, enabling memory to be attached on the fabric rather than only on the CPU’s DDR channels. CXL Type-3 devices can present capacity as OS-visible memory, making them a natural place to re-introduce persistence, with the possibility of scaling, pooling, and composability.
- Decouple persistent capacity from CPU sockets and DDR channel limits.
- Enable pooling/sharing models (with platform and fabric support).
- Offer a standard path to expose persistent regions through OS frameworks.
- Support heterogeneous hosts and composable infrastructure topologies.
CXL Persistent Memory: A Reference Architecture View
A common approach for CXL-attached persistent memory mirrors the proven NVDIMM-N pattern: fast volatile media for load/store access plus non-volatile media for retention, coordinated by device firmware and protected by hold-up energy. The device attaches as a CXL Type-3 endpoint, exposing capacity into the host’s memory map while remaining on the fabric.
At a minimum, a CXL persistent-memory design should address:
- Latency and bandwidth that remain “memory-like” for key hot paths
- Data retention across graceful shutdown and surprise power loss
- Well-defined persist/flush semantics (host visibility and ordering)
- Firmware-controlled save/restore with adequate hold-up energy to complete the copy
- Alignment with CXL persistence mechanisms (for example, platform-supported global flush paths)
On the host side, the goal is to surface persistent regions through standard OS memory and CXL frameworks, so applications can use familiar persistence libraries and operational tooling (monitoring, health, and recovery) without proprietary integration.
How a CXL Persistent-Memory Demo Typically Works
The demo featured Netlist’s NV persistent memory NVault™ solution using CXL and showed how a CXL-attached device can preserve and quickly restore memory contents after a power event. The flow mirrors earlier NVDIMM-style designs: on power-fail, a device-controlled save moves data from volatile to non-volatile memory using on-device hold-up energy, followed by a restore sequence before the host resumes memory use.
In a persistent-memory design, the hardware detects a power failure, triggers a firmware-controlled save, and uses stored energy to complete the data transfer. On the next boot, the device restores the region before host access is granted.
This illustrates an important principle: persistence should be deterministic and enforced below the application layer. If the platform loses power at an arbitrary point in time, the system should be able to recover to a known-good state with a well-defined save/restore sequence.
Where CXL Persistent Memory Helps
CXL persistent memory is a fit when workloads need fast restart or durable in-memory state without pushing every write through storage I/O paths.
- In-memory databases and stateful services with rapid recovery
- Storage metadata (journals, intent logs, caching) where durability and latency matter
- HPC restart to reduce overhead versus traditional storage checkpoints
Conclusion
NVDIMM-N validated the value of persistent memory, and JEDEC helped standardize the behaviors that make it reliable. CXL enables scalable, fabric-based persistence, maintaining system-level consistency. If you’re designing or evaluating CXL memory systems, consider where persistence changes your restart model, recovery objectives, and infrastructure topology—and validate the end-to-end behavior (power fail detection, save/restore, and OS exposure) with a simple signature-and-reboot test. Learn more about Netlist’s CXL persistent memory solution at https://netlist.com/cxl-nvvault/.
Resources
- CXL 3.0 White Paper
- CXL 3.1 Specification
- Linux CXL Documentation (Kernel support for CXL memory and device management)
- JEDEC NVDIMM Standard (background on persistence behaviors and management concepts).
- Netlist’s NV persistent memory NVault™ solution using CXL