On November 12, 2026, the UCIe Consortium released UCIe 4.0, the latest version of its chiplet interconnect standard. The revision adds a new specification for connecting a compute SoC to a memory logic die within a package, allowing memory control to be separated from the compute side. Chiplets are small semiconductor dies that are combined and placed in a single package, and UCIe is the common standard for connecting them.
What sets UCIe 4.0 apart is that it strengthens not only data transfer but also status monitoring across multiple dies and recovery when faults occur. UCIe 2.0 introduced a common foundation for management, testing, and debugging, and 3.0 added support for high-speed transfer at 48/64 GT/s, among other things. Building on these technologies, 4.0 further advances more efficient memory connections and the standardization of system management features.
UCIe.mem: Separating Memory Control into a Different Die
The newly introduced "UCIe.mem" is a specification for connecting a compute SoC to a memory logic die via UCIe-S or UCIe-A. The memory controller that communicates with HBM or LPDDR is placed on the logic die side, so the compute SoC no longer needs to incorporate memory control circuitry. This configuration can reuse UCIe's existing physical layer, adapter, compliance testing, and package infrastructure as is.
Between the compute SoC and the memory logic die, memory requests and responses are transferred rather than low-level DRAM signals being exchanged directly. The specification uses an encoding scheme that stores two requests or four responses in a 16-byte slot within a "flit," a 256-byte transfer unit, which reduces overhead such as headers and acknowledgments. According to the UCIe Consortium's technical explainer, data transfer efficiency reaches about 94% for read-heavy traffic using 64-, 128-, and 256-byte payloads. The upper limit of 93.75% given in the announcement materials also rounds to about 94%.
The consortium also says UCIe.mem's bandwidth density reaches roughly 2.5 TB/s/mm. This is a metric of transfer bandwidth per millimeter of die edge, and differs from the effective memory bandwidth available across the whole chip.
Improved Connection Density and Power Efficiency
UCIe 4.0 focuses on improving connection density and power efficiency rather than raw transfer speed. The 48/64 GT/s transfer rates were already introduced in the previous generation, UCIe 3.0, and 4.0 refines the bump layout for UCIe-S connections at this speed tier. According to the consortium, bandwidth density per unit of die edge length improves by about 20%, and bandwidth density per unit of area by about 10%. The technical explainer also notes that the die edge dimension has been standardized at 1143 µm.
To improve power efficiency, an optional "co-optimization profile" has been added for 64 GT/s. This profile assumes that the characteristics of the die on the other end of the connection are known, that compatible manufacturing processes are used, and that power rails are shared. For UCIe-S, wiring optimized for shorter-distance communication is also required. It can be applied to both UCIe-S and UCIe-A and uses techniques such as QDR, direct sampling, and reduced signal swing.
The consortium's announcement says the profile improves energy efficiency by 30 to 80%. The technical explainer, meanwhile, says link power consumption can be reduced by 30 to 80% when specified conditions are met. Both are published figures for the die-to-die communication link, and do not mean that system-wide power consumption falls by the same proportion.
Standardizing Chiplet Status Monitoring and Reset
When chiplets from different manufacturers are combined in a single package, differences in security management and test methods become a challenge. UCIe 4.0 expands its management features so that the status of each die can be checked in a common way even in such environments.
The new TRoCs report each die's lifecycle, security state, and test interface configuration through the existing register access mechanism. The Root of Trust (RoT), also called the Security Director, verifies the reported state using a cryptographic challenge-response method. This mechanism strengthens defenses against spoofing, replay, and man-in-the-middle attacks.
Security for management communication has also been reinforced. Because management packets may pass through intermediate dies or the interposer, UCIe 4.0 adds bidirectional integrity protection to the existing Management Transport Protocol (MTP), enabling source verification and detection of tampering and replay. Sessions established between a manager and a management endpoint are refreshed after the whole package (SiP) or an individual die is reset. Key establishment uses a method based on NIST SP 800-56C and supports management endpoints both with and without a random number source, and the confidentiality of communication contents can also be protected as needed. In addition, a common mechanism has been introduced for provisioning identifiers, configuration information, and security credentials after manufacturing or during operation.
Reset behavior can also now follow a common procedure across multiple dies. Cold Reset returns a die to its default power-on state, while Warm Reset allows vendor-specified state to be retained. Page 6 of the public white paper distinguishes the reset behavior required of individual chiplets from the scope left to the implementation of the package as a whole.
| Scope | Standardized functions and what is left to implementers |
|---|---|
| Individual chiplets | Specifies power-on behavior, common Cold/Warm Reset behavior, required reset inputs and electrical and timing requirements, and registers that record reset initiation, status, and cause. The state retained during Warm Reset is defined by the vendor. |
| Whole package (SiP) | Reset sources, connection topology, and control procedures are left to each implementation. |
In other words, while UCIe 4.0 standardizes reset behavior for individual chiplets, it leaves to each manufacturer's design the order in which multiple dies are reset and how the whole system is recovered.
For status monitoring, in addition to the method in which the manager periodically polls each die, event notification can now be used as needed. This reduces the communication volume and latency associated with status checks. The specification supports discovery and configuration of notification destinations, event delivery, and optional acknowledgments and logging, and includes rate limiting to prevent notifications from flooding the system. The notification latency targets are under 1 µs for messages passing through one sideband segment between adjacent dies, and under 100 ns for priority sideband events between physically adjacent dies. However, these are design targets under specified conditions, not performance figures confirmed by measurement.
Fault Notification During Communication Failures and In-Operation Signal Monitoring
UCIe 4.0 adds a dedicated unidirectional open-drain signal so that critical faults can be reported even when the normal communication path is unavailable. This signal is independent of UCIe's main and sideband paths, and its power supply can also be isolated as needed. This makes it possible to build a mechanism that notifies other dies or the management side of a critical failure even when normal communication functions have stopped.
Signal quality monitoring has also been strengthened. In addition to the existing CRC, per-lane error checking, and eye margin reporting after link training, an optional feature for measuring eye margin during operation has been added. Eye margin is a metric of how much headroom the receiver has to correctly identify a signal, and the new feature can measure it without stopping normal link operation. The information obtained can be used for system-wide health monitoring and functional safety mechanisms.
UCIe 4.0 maintains backward compatibility with all earlier versions, and the specification is available to the public on request. However, neither the announcement nor the technical explainer gives specific timing for compatible products or mass-production plans. Going forward, attention will turn to what memory configurations products adopting UCIe.mem will enable, and how much power reduction can be achieved when the co-optimization profile's conditions are met. How each manufacturer implements the chain from fault detection to individual die reset and package-wide recovery will also be an important point in judging the standard's practicality.