Produced by ZhiNengZhiXin

As advanced packaging propels chiplet design into the mainstream, the significance of the UCIe (Universal Chiplet Interconnect Express) standard has become increasingly pronounced.

The introduction of UCIe 2.0 brings a multitude of expanded features, paving the way for a more open and interoperable ecosystem in the future. However, it has also sparked debates over its perceived "complexity." The myriad of newly added features are not mandatory but tailored for open systems requiring multi-chip collaboration, allowing users to adopt them as per their needs.

This design philosophy not only supports customized packaging solutions but also imposes heightened demands on chip design companies, IP vendors, and ecosystem developers.

Part 1

The Real Intention Behind Optionality:

Not Complexity, but Openness Reserves

Upon its release, UCIe 2.0 ignited fervent discussions in the chip design and packaging sectors, often labeled as "burdensome" and "bloated," stemming from misconceptions about the sheer number of features introduced in the new version.

As a standard protocol, UCIe does not mandate all implementers to adopt every feature comprehensively. Notably, most of the new features in UCIe 2.0 are classified as "optional," enabling developers to tailor the feature set based on the packaging architecture, system type, and interconnect requirements. This allows for flexible pairings, ranging from minimal interconnect units to highly complex modular systems.

Currently, most advanced packaging projects leveraging chiplets focus on large IDMs or Fabless enterprises with comprehensive design capabilities.

These enterprises typically dismantle the logic core, cache, I/O, or other functional modules into multiple bare chips based on deconstructed SoCs, integrating them through advanced packaging to overcome limitations of single-chip SoCs in terms of process, power consumption, or mask size.

In such scenarios, all chiplets are designed by the same team, rendering interoperability a non-issue, and additional management and configuration features unnecessary.

UCIe 2.0, however, targets the nascent yet highly promising open chiplet market.

In this vision, chip developers no longer need to construct the entire system from scratch but can procure functional chiplets from an open ecosystem, akin to how software developers acquire IP cores today.

While this prospect is appealing, it is also fraught with challenges. In an open ecosystem, standardized protocols are essential for coordinating system management tasks such as boot-up, configuration, and error handling among chiplets, rather than relying solely on a single data path.

The management architecture introduced in UCIe 2.0 is tailored for this vision, encompassing capabilities like communication link training, chiplet configuration, telemetry, and fault dumps. It further defines management command paths on sideband channels and main data channels.

Implementers can choose to enable only boot initialization based on system needs or extend it to functions like power management, thermal control, and debugging. For packaging projects relying solely on internally designed chiplets, these mechanisms can be ignored.

This "management as optional" philosophy is also evident in the design of the interface and register architecture. For instance, UCIe employs a functional structure to define information within a chiplet, such as register mappings, vendor IDs, and device IDs, which are only activated when the system needs to identify chiplets from different vendors. These register read operations incur minimal latency, ensuring system efficiency.

In terms of implementation, UCIe management features are built upon high-level communication protocols rather than the PHY physical layer, facilitating flexible adaptation through firmware and software. The lowest-level implementation even supports "blind boot," completing basic interconnect configuration without processor intervention to ensure initial system connectivity.

The standard itself exercises restraint at the boundary between "mandatory" and "optional." For example, while the specification defines a channel order flip mechanism for flexible routing in various layouts, if the designer determines that all chiplets will connect in one direction, the relevant circuit implementation can be entirely omitted. The standard specifies behavior rather than circuit structure, safeguarding different companies' implementation freedom.

Part 2

From Closed to Open:

The Transition from Chip Customization to Chiplet Ecosystem

At present, chiplet design is primarily the result of vertical integration, lacking market drivers for cross-company chiplet interoperability.

Even the widely used HBM high-bandwidth memory is often integrated with the main logic chip through stacking rather than as a truly independent chiplet interconnected via UCIe. However, looking ahead, a chiplet trading ecosystem akin to the IP market may gradually emerge.

In this scenario, different vendors need to achieve plug-and-play chiplets within the package, posing challenges to both protocol flexibility and standardization depth. UCIe 2.0 anticipates this future by not compelling current designers to adopt complex mechanisms but by providing a toolkit for players committed to an open ecosystem.

From the perspective of chiplet suppliers, UCIe's diversity is a double-edged sword.

On one hand, it supports a wide array of scenarios such as AI, automotive, HPC, and aerospace.

On the other hand, it makes it challenging for IP vendors to support all styles simultaneously.

For instance, some vendors prefer versions compatible with EMIB or CoWoS, with bandwidth requirements ranging from half of the standard 64 transmit + 64 receive channels. This necessitates chiplet designs to strike a balance between support and power consumption. In current closed projects, many enterprises are reluctant to introduce unnecessary logic modules into the package to conserve area and power consumption, prioritizing minimal interconnect mechanisms over complex management and configuration systems.

For enterprises with a more open vision, UCIe 2.0's management framework, sideband channels, performance telemetry, and other mechanisms become essential capabilities for future systems.

Another highlight of the standard is its ease of implementation. Unlike software IP modules that still require significant glue logic to integrate into an SoC, chiplets achieve hardware-level interface standardization under the UCIe protocol specification, requiring only physical connection and configuration recognition for collaboration, significantly reducing barriers to multi-vendor cooperation. This marks a significant step in the evolution from the IP ecosystem to the chiplet ecosystem.

The standard itself does not dictate the implementation method. It avoids defining circuit details in the design and focuses solely on behavioral specifications, preserving vendors' innovation space and enhancing the protocol's acceptability. As multiple vendors have emphasized, UCIe's goal is not to specify implementation paths but to provide a common language.

Regarding the "discovery" function, the standard faces issues with terminology extension. The term "discovery," inherited from PCIe, often leads to misunderstandings, as its intended function is to enable automatic chiplet identification within a package rather than simple existence verification.

The relevant mechanism encompasses steps such as identification configuration, register reading, and connection confirmation. In the future, when combined with automated toolchains and debugging platforms, it will become an indispensable capability for the open chiplet market.

Summary

UCIe 2.0 embodies a forward-thinking layout for the future chiplet ecosystem rather than a one-size-fits-all intervention in current packaging solutions. The standard strikes a new balance between flexibility, composability, and high-performance goals, preserving multiple implementation paths and providing choice space for enterprises at varying levels of maturity.

For developers new to chiplet design, UCIe can still be utilized as a lightweight interconnect protocol. For enterprises committed to building chiplet platforms, management features and interoperability mechanisms become the cornerstone of the architecture. As the chiplet market gradually shifts towards openness and interconnectivity, UCIe's optional mechanism may prove to be the pivotal factor determining the ecosystem's prosperity. The standard's value lies in its adaptability to the pace of evolution rather than presupposing an endpoint.