# Managed vs. Unmanaged NAND: Choosing the Right Approach

> NAND flash comes in two variants: managed and unmanaged (raw) NAND. Each has different implications for real-time database performance.

> ## Unmanaged NAND (Raw NAND)

> With raw NAND, the host system is responsible for handling key management tasks, such as:

> - Wear leveling - Distributing write operations evenly to prevent premature wear.
> - Bad block management - Detecting and remapping faulty memory blocks.
> - Error correction (ECC) - Ensuring data integrity at the driver level.

> Raw NAND is typically used in systems where performance, cost, or space constraints demand direct control over flash operations. From a real-time database perspective, raw NAND offers full control over transaction handling, helping to minimize unpredictability. However, it also adds complexity—it requires a Flash Translation Layer (FTL) or a dedicated NAND controller to manage data storage efficiently. Unmanaged NAND is better suited for real-time embedded systems that require precise control over storage operations and predictable storage access latencies.

> ## Managed NAND

> Managed NAND, such as eMMC, UFS, or NVMe SSDs, comes with a built-in controller that handles all the low-level NAND management tasks automatically. This means the host system doesn’t have to worry about wear leveling, bad blocks, or error correction.

> Database kernel, middle-ware and applications have much less control over performance and its predictability of media access. Background operations performed by the integrated controllers such as wear leveling and garbage collection can lead to highly variable write latency—sometimes differing by orders of magnitude. While this is tolerable in many applications, it can be problematic for real-time systems that require consistent, bounded timing. For these scenarios, raw flash paired with externally controlled, deterministic data management mechanisms is often the better choice. Managed NAND is great for applications that need easy integration and reliable, standardized performance without additional development effort.

> eXtremeDB/rt supports both managed and unmanaged flash storage devices. Managed flash is accessed through the xfile module (libmcoxfile), while raw flash is supported via the xflash module (libmcoxflash). Both xfile and xflash implement database transactions, providing higher-level kernel components with transaction commit and rollback capabilities.

> To access physical media, xfile requires file system wrappers, which expose file system-like pread/pwrite operations. The standard eXtremeDB/rt distribution includes wrappers for various file systems and raw block devices.

> On the other hand, xFlash integrates database transactions directly with the flash management layers. It eliminates the need for a file system or any intermediate software to handle NAND flash specifics. Instead, it works directly with low-level drivers from the hardware manufacturer to communicate with the flash device. These drivers typically provide essential flash operations such as read, program, copy, and erase.

> ## Flash Memory Connection Interfaces

> The interface between flash memory and the host CPU has a significant impact on system performance, especially in real-time applications. Interface choice affects data latency, throughput, design complexity, and the ability to meet transaction deadlines.

> Both NOR and NAND flash memory devices use either serial or parallel interfaces: Serial interfaces (e.g., SPI, QuadSPI) are simple to implement, with low pin count and minimal board complexity. Dual and Quad SPI variants increase throughput to 2 or 4 bits per clock cycle. Serial flash typically follows JEDEC standards for identification, but communication protocols are vendor-specific, requiring custom low-level drivers. Normally NAND flash devices use serial interfaces in compact systems with simplified design, lower bandwidth requirements.

> Parallel interfaces support higher data rates by transferring multiple bits per clock cycle. These interfaces are more complex but preferred in high-throughput applications. Many parallel NAND devices comply with the ONFI standard, enabling development of vendor-agnostic drivers. Proprietary features (e.g., OTP memory or unique IDs) may still require special handling.

> Parallel NAND interfaces transfer multiple bits per clock cycle, enabling high-speed data access, making them well-suited for in data-intensive applications database storage applications.

> From a real-time database perspective, both interface types can deliver predictable access times, which is essential for deterministic transaction scheduling. This is achievable through careful interface selection, driver design, and understanding of access patterns.

> ## Predictability of Flash Memory Timing

> Independent of the connection interface—serial or parallel—flash memory access times are inherently predictable. This predictability stems from the stable electrical characteristics of flash memory cells, which define fixed read, write, and erase latencies based on the chip’s internal architecture. These timing parameters are specified by the manufacturer and remain consistent across interface types, providing the deterministic behavior required for real-time system performance.

> The timing diagram below illustrates the read process for an industry-standard SPI-based serial flash memory.

> Key signals involved include:

> - CS (Chip Select): Active-low signal that selects the target flash chip.
> - SCLK (Serial Clock): Governs timing for data transfer.
> - SI (Serial Input): Transfers data from the host (MCU) to the flash chip.
> - SO (Serial Output): Transfers data from the flash chip to the host.

> The diagram shows how these signals interact over time. Each step of the read sequence consumes a fixed number of clock cycles:

> The command (e.g., 0x03 or 0x0B) requires 8 clock cycles. The 24-bit address requires 24 clock cycles. A full page transfer (e.g., 2,112 bytes) takes 2,112 × 8 = 16,896 clock cycles.

> The total read time is determined by the bus clock frequency and the number of cycles required for each operation stage. This level of cycle-level precision enables eXtremeDB/rt kernel to schedule flash access operations within bounded timeframes, even when using commodity SPI flash devices.

> Parallel interfaces support multi-bit transfers per clock cycle, reducing external communication latency. However, flash memory’s internal operation times—such as read, program, and erase latencies—remain fixed by design and are unaffected by the interface type. This consistency ensures predictable performance, which is essential for eXtremeDB/rt kernel. The same timing stability applies to internal operations defined by the ONFI protocol, including Page Read, Cache Read, Program/Erase, Unique ID Read, and Feature Set commands.

> The block diagram illustrates how, regardless of the interface type, the fundamental read, write, and erase timings of flash memory remain stable and predictable across different connection methods: