SK hynix to place custom tiny CPU cores in its SSD controllers to ease Arm load as drive speeds rocket

SK hynix has detailed plans to reduce reliance on power-hungry CPU cores with an in-house core named a Hynix Transaction Processing Unit (H-TPU). Not to be confused with an AI accelerator, an H-TPU would assist with repetitive work handled by an SSD, which usually demands more cores on a controller as drives get faster. These new cores are placed in clusters and would handle routine I/O with a four-stage, in-order pipeline, while management is left to the traditional Arm CPU. The new, tiny cores are claimed to draw only about 2.5% of a general-purpose CPU core’s power, with just around 4% of its area. Now, the company plans to apply H-TPU across its portfolio of products, TheElec reports.

The company’s VP of system-on-chip (SoC) design, Koo In-jae, spoke at ISOCC 2026, the International SoC Design Conference, earlier this week, saying that SSD controller CPUs are at their limit on power and area. In the talk, titled “From SSD Controllers to AI Memory SoCs,” he said that PCIe bandwidth doubles every generation, and controller CPU clocks and control capability reportedly can’t keep up. SK hynix reportedly plans to apply H-TPU across its NAND products, including next-gen enterprise SSD controllers. That’s where the unending chase for IOPS makes the problem most evident.

Koo’s comments underline the issue of scaling, which is evident in the “more cores” solutions found in competitor products. Marvell’s PCIe 6.0 Bravera SC6 uses 12 Cortex-R82 cores in two six-core clusters with three Cortex-M7 cores and a secure Cortex-M3. Compare this to its PCIe 5.0 predecessor, the Bravera SC5, which lists 10 Cortex-R8 and Cortex-M7 cores plus a Cortex-M3 for security. Core counts have climbed with PCIe speeds out of necessity.

SK hynix’s answer is a core of its own design: the H-TPU, kept small and programmable. It comes with a dedicated compiler and other development tools for specialized code. It’s stated to use a four-stage pipeline with in-order, or sequential, execution. It is not superscalar, does not use out-of-order units, and should not be confused with a tensor processor for AI. It is designed to handle read and write command processing, manage metadata, and handle buffer control, all repetitive tasks.

Storage control requires more than 100 detailed functions, which is not ideal for a monolithic CPU. Instead, SK hynix broke those functions up and spread them across “dozens of small TPU clusters,” according to ZDNet Korea (translated). Each H-TPU therefore has a specialized job. The total number of H-TPUs is more than 100; the function count above is a separate figure. However we currently have no details on how many cores each cluster holds.

The main CPU still handles error recovery and exception handling, plus storage-policy management, so the H-TPU complements the CPU: offloading, not replacement. The design idles the cores a given I/O doesn’t need, which reportedly drop into a minimum-power mode. Neither report names the CPU core behind SK hynix’s 2.5% power and 4% area figures.

Splitting the workload this way is not a new idea. Phison’s CoXProcessor, which pairs Cortex-R5 cores with hardened macros to offload repetitive firmware at wire speed, has been in products for some time. The company’s E18 SSD controller uses two lower-clocked Cortex-R5 cores to supplement the three main ones. On the enterprise side, Phison’s X1 used two Cortex-R5 cores plus up to 32 “micro cores,” each dedicated to one or two tasks. H-TPU takes this approach to a larger scale.

While the talk itself is light on detail, we discovered multiple SK hynix patents that describe a similar split between small cores and a CPU. U.S. patent 11,675,537, first filed in Korea in November 2020, details a CPU-run control plane and an I/O plane of many small processors, sorted into four groups by job. A command passes through all four in order: host for ingestion, cache, map, and NVM to the NAND. The processors “configure a pipeline for the data I/O operation” this way, letting the CPU handle any exceptions. That pipeline runs across many cores and is unrelated to the four-stage pipeline inside each H-TPU.

In the patent’s example, each small core is around “200,000 logic gates” rather than the “seven million logic gates” of the CPU, or about 2.9% of the CPU’s gate count. These are not fixed elements, as “firmware may be driven in each of the TPUs,” making them more adaptable than the hardware circuits the patent calls “difficult to modify.” The patent spells out TPU as “Tensor Processing Units,” but, again, this should not be confused with AI accelerators. H-TPU shares that programmable approach, but the next step SK hynix described moves some routine jobs into fixed hardware.

This next step is hardware automation (HWA), with command processing, address lookup, and buffer copies moved to dedicated circuits. The CPU and H-TPUs still handle exceptions and key policy decisions. Moving to this framework is meant to keep completion times predictable, which is necessary with I/O, especially for today’s high-IOPS enterprise SSDs.

SK hynix has filed on fixed-hardware paths before, with a 2014 filing by its San Jose-based unit and, later, with U.S. patent 12,216,914, first filed in Korea in 2022. The latter describes a “write automation circuit” and says “a task without intelligent control can be handled or processed through the hardware layer,” while firmware keeps jobs such as garbage collection. The former went further, sending basic I/O commands down a path “completely implemented in hardware,” with anything it couldn’t handle being sent upstream.

The H-TPU itself is reportedly being used in “Storage Next,” Nvidia’s name for the joint AIN P project with SK hynix. Storage Next targets 512-byte or more limited access with NAND, which traditionally aims at higher operating sizes. SK hynix also plans to apply it to high-bandwidth flash (HBF), which the outlet said is due next year. HBF stacks NAND dies for AI inference, targeting high-bandwidth memory (HBM) levels of bandwidth but with far more capacity, with up to 512GB per stack versus 64GB for HBM4.

For HBF, AI inference reads outnumber writes around 300,000 to 1, with the AI compiler and runtime passing pre-analyzed dataflow to the HBF SoC. Proper buffer management and prefetching based on that dataflow are meant to hide the slow NAND latency behind compute. Size is important in HBF stacks, so a traditional multi-core Arm design is likely less practical.

H-TPU has yet to be proven in an actual enterprise SSD controller product, and no date has been given. The move from general-purpose CPU cores to specialized single-job cores and circuits matches the type of workload SSDs handle, and the demands on storage are only increasing as AI servers become memory-constrained.

SK hynix’s statements and patents support an evolution to H-TPU and beyond to HWA, with H-TPU itself headed for traditional NAND and next year’s HBF. SSD controller manufacturers must be willing to adapt, as simple scaling is suboptimal even at current PCIe levels, let alone the speeds promised for PCIe 7.0 and 8.0, the latter headed for final ratification in 2028.