They’re necessary, but insufficient for a marketplace.
Key Takeaways
Today’s chiplets exist in silos. In a given package, they’re all sourced from the same company (except for HBM), and that company controls everything.
Achieving the industry’s vision of a chiplet marketplace requires more structure, however. The approach doesn’t work if every chip company designs and manufactures its own proprietary chiplets. A chiplet marketplace requires standards to ensure interoperability and physical composability, so it’s embarking on multiple standardization efforts to pave the way for off-the-shelf chiplets.
Interconnecting chiplets has proven to be the highest-priority standard. “Some of the toughest problems involve achieving effective communication between chiplets and managing the complexities of routing and connectivity,” noted Kendall Hiles, senior product specialist for a 3D-IC packaging flow at Siemens EDA, in a joint webinar with Alphawave Semi.
The chip-to-chip interconnect standards, such as Bunch of Wires (BoW) and UCIe, have addressed that concern, but the industry requires far more to enable plug-and-play chiplets that snap together like LEGOs.
“If you’re going to construct a system out of chiplets that are off-the-shelf, then a lot of interoperability concerns are important, and so you need to define all these layers on top of the data interface,” said Manuel Mota, senior staff product manager for high-speed interface IP at Synopsys.
Additional standards are in place or in development, covering everything from package descriptions to system architectures. These standards will be necessary for lubricating a general marketplace, where system implementers can pick chiplets from the catalogs of different manufacturers and combine them into innovative systems. Such standards won’t guarantee a marketplace’s success, since other considerations will factor into its future, but a lack of such standards will almost certainly guarantee failure.
What kinds of standards are necessary?
The list of standards targets is expansive. Different experts may have slightly different lists, but most cover the same basic requirements. Rob Kruger, product management director at Synopsys, assembled a wish list of standards the company believes are necessary for marketplace success. These include:
“Broader proposals for standards will eventually be helpful in classifying chiplets for design tools and build-out,” said Mike Alfano, chief architect and vice president of product at Chipletz. “However, there are architectural considerations that will drive near-term device adoption. UCIe, for example, is beginning to provide the wire-level framework for interconnectivity. We believe companies focusing on this physical level are crucial to the adoption of chiplets based on the real-world benefits that can be demonstrated.”
Much of the ongoing standards work is being managed by the Open Compute Project (OCP). The organization doesn’t always create standards from scratch. It often works with other standards bodies, such as JEDEC and IEEE, to motivate features and then endorses specific standards.
“When we look at true interoperability, it is much more than just physical wires talking to each other,” said Anu Ramamurthy, project co-lead, open chiplet economy subgroup at the OCP, in a presentation at the 2026 Chiplet Summit. “It is an entire ecosystem or an entire setup, starting from the physical layer all the way up to software, where you treat all the discrete dies in a system as a single structure. We at the OCE (Open Chiplet Economy, an OCP workgroup) are starting to look at this more holistically, as it’s not just the wires. How do we communicate across this entire stack, all the way through the firmware?”
Standardizing package aspects
JEDEC has been standardizing packages for decades, and JESD-030 provides for a textual description of package characteristics in XML. The OCP has worked with JEDEC, contributing its chip data exchange proposal, CDXML, to the organization. The latest revision, JESD-030O, includes that content.
“With JEDEC, we’ve created a way to describe these chiplets — not just the physical and electrical aspects, but all the way to the assembly, the packaging, the materials that are used,” said Ramamurthy.
The standard describes a format for specifying elements such as:
This provides numerous EDA layout and verification tools, along with the information necessary to complete those tasks automatically. While this has always been the case for JESD-030, the complexity of heterogeneous integration into advanced packages has introduced many new complicating factors that must be addressed. The updated standard thus provides the necessary additional information.
JESD-030O was released in February of last year. Logging in to the members’ area is required to access it.
Standardizing a chiplet-based system architecture
A separate effort is underway to take Arm’s CSA, which Arm recently donated to the OCP, and develop it into an instruction-set-architecture-agnostic Foundation Chiplet System Architecture (FCSA). It provides a means of piecing together systems from component chiplets and specifying the nature of the chiplets so they can interoperate.
“Chiplets aren’t just a packaging trend,” noted Archana Cheruliyil, principal product marketing manager at Alphawave Semi, in the joint webinar with Siemens EDA. “They are becoming the architectural foundation that allows us to scale compute, manage power and deliver specialized functionality.”
Employing chiplets brings more requirements than simply instantiating soft IP. Each chiplet must have some fundamental building blocks that historically only large chips have required.
“Boot-up, debug, security, and other such infrastructure capabilities are extra functions, and they fundamentally make a chiplet into a mini-SoC,” said Mick Posner, senior product marketing group director at Cadence.
The specification provides for three levels of compliance, although there’s no high-level motivation for the lowest two (Level 0 and Level 1). Instead, various specific rules are tagged with the level they belong to. For the most part, each lower level’s requirements must be met at the next higher level. The level above Levels 0 and 1 is Full Compliance.
The spec describes two system configurations — compute-and-hub and compute-tile. The main difference is that, in the first one, system main memory, cache, and I/O are provided by a hub chiplet. In the second one, they’re provided in one or more compute chiplets. As a result, it defines two different compute chiplets.
The spec then goes on to define a variety of different chiplet types: compute (two types), hub, fully coherent expansion (two types, with one for remote translation), I/O, I/O coherent expansion (three types: translated, untranslated, remotely translated), and an I/O controller. Each element in the spec specifies aspects such as which chiplets it must connect to, how it deals with system memory and the MMU, and how it handles interrupts, security, and debug.
It goes into detail to define the chiplet interfaces as well as how they’re implemented. Both UCIe and BoW are called out as being supported by the standard.
Revision 1.0.0 became effective in February of this year. “Anyone can go to our contribution database and download it,” said Cliff Grossner, chief innovation officer for the OCP, at the Chiplet Summit, “This is the start of something that will go forward for quite some time.”
Standardizing design kits
In the same vein as process design kits (PDKs) and assembly design kits (ADKs, also called package assembly design kits, or PADKs), chiplet design kits (CDKs) are being defined. Exactly how they relate to other kits is a bit unclear, as CDKs were described as containing various sub-kits at the 2026 Chiplet Summit, but in an OCP document, CDK is shown alongside the other kits. The latter makes more sense in that a chiplet isn’t a package, so an ADK, for example, wouldn’t be part of a chiplet description but would work alongside it.
The various design kits include:
Each of these elements, with the exception of the JEDEC standard, is described in a white paper, but it bears similarity to a standard. For example, the ADK sets out rules that define tolerances, layers, geometries, pads, fiducials, and other elements used in assembling a package, including 3D design.
An MDK lays out critical material properties for components such as package substrates, interposers, redistribution layers, and 3D stacks. It allows documentation of a variety of physical properties, including electrical, thermal, structural, failure, optical, and other surface and mechanical properties.
A (P)TDK defines various test structures and flows and then lays out the XML schema defining pads, test modes, test-only pins, functional-only pins, shared test/functional pins, and sacrificial pads.
Version 1.0 of the white papers describing each of these, all released in January of 2025, are openly available.
Die-to-die updates
Although we’ve discussed chiplet interconnects over the last year, most of that news has involved UCIe. BoW has also seen a couple of recent updates.
First, a direct memory interface, BoW Memory, has been defined, intended to facilitate high-bandwidth, low-latency memory accesses. Second, BoW Flexi relaxes some of the requirements of BoW 2.0 for lower-cost, lower-performance systems. “What are you looking for? A low-latency, low-power, lightweight, low-area interface? That’s for BoW Flexi, where the absolute bandwidth is not the limiting factor,” said Ramamurthy.
While the main BoW spec targets high performance in advanced packages, not all systems have those characteristics. BoW Flexi, due out by the end of the year, provides an easier route for those designing chips running at about 4 Gbps in simpler, lower-cost packages.
Finally, just as UCIe has defined higher layers, the OCP has introduced what it calls a universal link layer. “It is PHY-agnostic, so you could put it over a BoW PHY. You could put it over a UCIe PHY,” Ramamurthy said. “As long as it follows a certain format, you will be able to communicate with the protocol layer.”
Removing marketplace barriers
These standards should help to remove many of the technical challenges holding back a chiplet marketplace. Many aspects aren’t new, but they do systematize ways of doing things rather than having everyone do it their own way.
The follow-on question will be how easily and quickly companies can use them to test the viability of off-the-shelf chiplets. Even with these standards sorted, it’s not yet clear whether the industry will embrace such chiplets. Practical and economic concerns remain, and a marketplace is by no means smooth sailing from here. It’s just a bit closer than it was before.
Referenced document links:
Related Articles
Assembly Design Rules Slowly Emerge
Assembly design kits will greatly increase efficiency, but custom methods prevail for now.
UCIe’s Major Technical Components Are Now In Place
Version 3.0 of the interconnect standard doubles bandwidth and supports new use cases and enhanced manageability.
Chiplets Vs. Soft IP: Different In Almost Every Way
A chiplet marketplace would require deep changes in the design-through-manufacturing flow.
 |
 |
 |
 |
 |
 |
 |  |
 |
 |
 |
Leave a Reply