Controller Architecture

Controller Roadmap: External Gen4 Silicon Plus In-House Firmware, and Converging Interfaces for JHC400

2026-07-15controller roadmap / in-house firmware / FTL

CORE 7 and TITAN 7 pair an external Gen4 enterprise controller with JH in-house firmware. This post explains the risk reasoning behind that split, what the firmware owns in FTL, QoS and ECC policy scheduling, and how the hardware abstraction layer and test evidence carry over to the in-house JHC400 controller platform.

Why Start With External Silicon

J750 and J770 are in product definition / EVT, targeting 2026 Q4–2027 Q1. Converging controller silicon and enterprise firmware inside that same window stacks two risk curves on top of each other: a controller respin is measured in months, while firmware convergence comes from long regression cycles and workload coverage. CORE 7 and TITAN 7 therefore pair an external Gen4 enterprise controller with JH in-house firmware — the hardware interface is fixed early, the parts that need repeated tuning stay in firmware, and regressions run continuously on the internal JH-E4U-C engineering platform.

What the In-House Firmware Owns

  • FTL and endurance budget: J750 and J770 share the same 3D enterprise TLC media and the same controller; they differ in over-provisioning and write-amplification budget. J750 spans 1.92/3.84/7.68/15.36TB at 1 DWPD over five years, J770 spans 1.6/3.2/6.4/12.8TB at 3 DWPD. One FTL codebase has to retune garbage-collection watermarks, hot/cold separation granularity and mapping-table residency against the OP ratio before 4KB random write moves from 300 KIOPS to 600 KIOPS.
  • QoS scheduling: the 65/10 µs figures on the spec sheet are QD1 averages for 4KB random read/write. The engineering problem is holding tail latency down while garbage collection, wear levelling and refresh run concurrently. The firmware budgets background work and yields dynamically to host pressure instead of draining a whole superblock in one pass.
  • ECC policy scheduling: the LDPC engine sits in the controller, but firmware decides when to escalate from hard to soft decision, when to trigger read retry and read-level shift search, and which blocks to migrate early — based on P/E count, retention time and error history. A UBER of ≤1 sector per 10^18 bits read has to be sustained across the full five-year warranty window by that policy, not by factory raw bit error rate.

Migrating to JHC400: Freeze Interfaces First

The in-house JHC400 platform is where the roadmap ends, but the move must not become a firmware rewrite. Controller-coupled code is being pulled into a thin hardware abstraction layer: register access, DMA descriptors, LDPC engine calls and NAND channel timing each go through a defined interface, and FTL, QoS and ECC logic never touch registers directly. Swapping controllers then replaces the abstraction implementation and low-level drivers, while the upper-layer algorithms and parameter tables migrate with their accumulated regression history.

Reusing One Evidence Chain Across Two Generations

Interface convergence is paired with validation convergence. The enterprise baseline — PLP, end-to-end protection with T10 DIF/DIX, multiple namespaces, NVMe-MI, TCG OPAL / Secure Boot / Sanitize, telemetry, online update and rollback — is expressed as host-side assertions that make no assumption about the controller, so rerunning them on JHC400 is regression rather than starting a test library from scratch. The in-house JH-ZS101 test system handles 480 NVMe SSDs per run, with zoned thermal control and remote power cycling, keeping sample-hungry work such as burn-in and power-loss cycling inside an acceptable schedule. SR-IOV and OCP-related capabilities are staged as P1 precisely so this evidence chain stabilises within the P0 scope first.

Keywords
controller roadmapin-house firmwareFTLLDPC error correctionJHC400J750J770hardware abstraction layer