UFS Storage: The Parallel Full-Duplex Alternative to eMMC

One bus, one job at a time: the half-duplex bottleneck

Every eMMC you've ever designed around has one hard structural limit. It runs a half-duplex 8-bit parallel bus. That means the same physical lines carry both reads and writes — one or the other, never both. The JEDEC eMMC spec is explicit: at any given instant the device is either sending a command and response, or moving data, or doing nothing. The spec's own example shows the sequence: host issues CMD18 (read), waits for the R1 response, receives the data block, and only then is the bus free for the next operation.

For a camera firmware blob that boots once and then idles, that's fine. You read the firmware, it goes to RAM, and the bus sits quiet for the rest of the product's life. But the moment your design wants to read and write at the same time — 4K video capture to flash while a telemetry logger writes timestamps to a separate partition, while a diagnostics app reads config — the bus becomes the bottleneck. Commands queue up behind each other. The command queue in an eMMC is shallow, typically depth 1 to 3 per the JEDEC spec. Thirty outstanding requests wait in a line that can only process two or three at a time.

Here's the thing: this isn't a bandwidth problem you can solve by clocking the eMMC faster. HS400 runs at 200 MHz on the parallel bus, which is the practical ceiling of the architecture. The fundamental issue is that the physical layer was never designed for simultaneous bidirectional traffic. You can't add full-duplex to an 8-bit half-duplex bus without redesigning the silicon.

UFS splits the bus into independent read and write lanes

UFS (Universal Flash Storage) solved this by replacing the parallel half-duplex bus with a serial, full-duplex, lane-based architecture built on the MIPI M-PHY physical layer. Each UFS lane is a pair of differential signal lines — TX_P/TX_N for the host-to-device direction, RX_P/RX_N for the device-to-host direction. The transmit pair and the receive pair are electrically independent. Data flows in both directions simultaneously on the same lane, at the same time, without either direction blocking the other.

That's not just a speed improvement. It's a structural one. When an industrial camera writes a 4K frame to UFS, it doesn't stop the logger from reading the last ten seconds of events, or the diagnostics daemon from pulling a health report. The write goes out on the TX lanes, the reads come back on the RX lanes, and the two operations complete in parallel. The command queue in UFS is 32 entries deep per the JEDEC spec, and because the lanes are full-duplex, those 32 commands can be in flight concurrently — reads and writes interleaved — without the head-of-line blocking that cripples eMMC.

UFS 2.0 (2013) introduced M-PHY and UniPro with a per-lane rate of 5.8 Gbps. UFS 3.0 (2018) doubled that to 11.6 Gbps per lane, and UFS 3.1 (2019) kept the same 11.6 Gbps per-lane rate while adding power-management refinements. A dual-lane UFS 3.1 design therefore delivers roughly 2.9 GB/s of aggregate throughput, and because it's full-duplex, up to about 1.45 GB/s in each direction at the same time.

UFS 4.0 (2022) doubled the per-lane rate once more to 23.2 Gbps and improved energy efficiency by more than 45% over UFS 3.1. On a dual-lane UFS 4.0 device that works out to roughly 5.8 GB/s of aggregate throughput, with up to about 2.9 GB/s in each direction simultaneously. JEDEC published UFS 4.1 (JESD220G) in December 2024 as an update that keeps the same 23.2 Gbps per-lane rate while adding features, and the 5.0 spec (2025) will double the per-lane rate again to 46.6 Gbps.

The migration is real, but it's a decision, not a sentence

Let's be honest about what it takes to move from eMMC to UFS. It is not a drop-in replacement. The eMMC driver stack in your Linux kernel — the MMC subsystem under drivers/mmc/ — speaks a command-and-response protocol over an 8-bit parallel bus. UFS uses an entirely different transport: the UniPro protocol over M-PHY, with SCSI command descriptors (UPIU) instead of MMC/SD commands. You need a different host controller driver, different kernel configuration (enabling the ufs driver instead of emmc), and a different board-level power management sequence.

On the PCB side, eMMC routing is a set of parallel single-ended traces — CMD, CLK, DAT0 through DAT7. UFS routing is a set of differential pairs with tight impedance-matched length matching between the TX and RX lanes. If your board was designed for eMMC, re-spinning the storage section for UFS is a real engineering effort. The M-PHY PHY also needs a clean reference clock and specific termination resistors that aren't on an eMMC layout.

So for a product that's already in production on eMMC, and working fine, and meeting its spec — don't migrate just because UFS is faster. The migration cost is a decision. You weigh the one-time NRE (new design entry) against the benefit of full-duplex I/O for the next product generation. For a new design targeting 2025 and beyond, the question is the reverse: why are you starting with eMMC? Unless your hardware team can't support UFS host controller IP, or your BOM budget is so tight that the delta is a dealbreaker, the default should be UFS.

Where full-duplex actually matters: three industrial use cases

The full-duplex architecture isn't a marketing distinction. It opens a class of workloads that are impossible, or at best painful, on eMMC.

Automotive and ADAS data recording. A modern ADAS stack has multiple camera sensors feeding frame data at 30–30 fps, an event logger writing timestamps and state changes on a separate timer, and a diagnostics interface (OBD, UDS) that a technician can query at any time — including while the system is actively recording an event. On eMMC, these three traffic patterns share one bus and one shallow command queue. On UFS, the camera writes and the event-logger reads run on independent lanes, and a UDS diagnostic read can interleave without stalling the recording. The JEDEC UFS spec specifically calls out automotive as a primary target application for this reason.

Industrial machine vision and 4K inspection. An inline inspection system captures 4K video at 60 fps, writes it to local storage for traceability, and simultaneously reads a calibration model from the same drive to run real-time defect detection on each frame. The model is a few hundred MB and is loaded once per batch, but the inference data — the feature vectors computed from each frame — streams continuously. On eMMC, the model load and the feature stream contend for the same bus. On UFS, the model read (on the RX lanes) and the feature write (on the TX lanes) proceed concurrently.

Edge AI and on-device inference. An edge AI device loads a neural network model (500 MB to 5 GB) from storage, then runs inference on an NPU while streaming new input data (sensor data, audio, video) into the model. The model load is a large sequential read; the inference input is a stream of small, unpredictable writes. On eMMC, the model load has to complete before inference can start cleanly, or the two operations interleave and the command queue backs up. On UFS, the full-duplex lanes let the model read and the input write happen at the same time, which matters when your inference cycle is 100 ms and you can't afford a 50 ms stall on a storage contention.

The bottom line

For new industrial embedded systems targeting 2025 and later, start with UFS. The full-duplex M-PHY architecture, the 32-deep command queue, and the 11.6–23.2 Gbps per-lane bandwidth aren't just faster numbers — they're a different I/O model that matches how modern industrial systems actually use their storage: concurrent, mixed-read/write, latency-sensitive.

For existing eMMC products that are working and meeting spec, migration is a business decision, not an engineering requirement. Do it when the next product generation needs the full-duplex behavior, not just the extra bandwidth.

Loongtion makes UFS modules for industrial applications. Contact us for a design review.

By Loongtion Technical Team