New connectivity standard brings performance improvements and a bunch of new features, but it may take years before they are adopted — and still may not result in an open chiplet market.
Plug-and-play chiplets are a popular goal, but does UCIe 2.0 move us any closer to that becoming a reality? The problem is that the current drivers of the standard are not after interoperability in the way that plug-and-play requires.
Released in August 2024, UCIe 2.0 touts higher bandwidth density and improved power efficiency, as well as new features supporting 3D packaging, a manageable system architecture, and more. The standard is being driven by key industry leaders, including ASE, Alibaba, AMD, Arm, Google Cloud, Intel, Meta, Microsoft, NVIDIA, Qualcomm, Samsung Electronics, and TSMC.
But what is required at the leading edge may be different than what is required for the rest of the market. “The standards are being driven by the data center guys, and the associated PHYs are targeting leading-edge nodes, which adds to the complexity,” says Kash Johal, founder of YorChip. “For the rest of the world market, which is lower-cost devices targeting 28nm down to 12nm, people just want standard building blocks and to tie those together using an FPGA or an ASIC. There is more of a need for a standard at the lower end. These customers really value reusability. If you’re designing at the bleeding edge, it’s pointless to limit yourself with an old standard.”
So who exactly is the standard for? “For applications in data center and AI accelerator sectors, UCIe will establish itself as the standard,” says Andy Heinig, head of Efficient Electronics in Fraunhofer IIS’ Engineering of Adaptive Systems Division. “For other applications, where the challenge is to build cost-effective, robust chiplet solutions, it is unclear whether UCIe is the right standard. In these cases further extensions or modifications, or even a different standard, will be needed.”
Within the data center, nobody is looking to a third-party chiplet market. “Standards like UCIe are useful as a baseline architecture and baseline set of features that you can adopt when it doesn’t stand in your way,” says Elad Alon, CEO of Blue Cheetah. “As soon as there is a knob you can turn that enables you to achieve a better cost or power, you turn that knob, because you’re not really giving up interoperability. You are just gaining some benefit to the end product.”
The hope is that the benefits of the new standard spread out across a larger market. “For captive chiplets, where both sides are designed together, UCIe 2.0 ensures streamlined in-house integration,” says Mayank Bhatnagar, product marketing director for die-to-die interface IP in Cadence’s Silicon Solutions Group. “For 3rd party ecosystems, its standardized interfaces and test/debug features promote seamless interoperability across vendors, driving broader adoption.”
There continue to be barriers to making broad adoption possible. “For a marketplace to thrive, there needs to be more interoperability,” says Mick Posner, vice president of product management for high-performance computing IP solutions at Synopsys. “This is still an emerging technology. Over the past year we have seen the introduction of new packaging technologies. If you look at high-performance compute, the packaging technology has not converged. You’ve got EMIB and CoWoS technology. Each of those is racing to offer differentiation across each other, but technically they have not converged. While die-to-die specs have matured and access to technology has become easier, you can’t mix and match.”
What’s new for 2.0
There are several areas in which the standard has advanced. “There were a lot of very good things that UCIe 2.0 has done,” says Blue Cheetah’s Alon. “The 3D part of it was very well done, fleshing out a lot of the details, expanding the range of footprints and configurations. It is moving in the right direction.”
And while few people are yet tackling true 3D chips, there will be long-term benefits. “UCI 3D is brilliant from an interoperability standpoint, because the channel almost doesn’t exist,” says YorChip’s Johal. “One die is talking to another die. The PHY is trivial. It’s basically an inverter, so it’s as close to being within the same chip as possible, even though it’s two chips. There’s no serialization, there’s no training, no DLL, no equalization — none of this sexy stuff that takes power.”
It will take a few steps to get there. “UCIe 1.1 offers interoperability at the PHY and die-to-die layer, but not at the software and management layer,” says Luis Rodriguez, engineering site lead with Siemens Digital Industries Software. “Most of the UCIe 1.1 projects are single die to single die. UCIe 2.0, with the system architecture and the management layer, should allow for complex topologies and a standard way of managing, debugging, and running diagnostic tools on a package that has complex UCIe topologies.”
Others agree. “Let’s say you have multiple chiplets within the system,” says Synopsys’ Posner. “The system needs to come up, and there needs to be a protocol that runs across either the main band or a side band of the UCIe to manage that bring up. You’re going to have one of the dies within the system that is going to be the orchestrator of the system. Maybe it’s the one where you have your main testability port, be that a JTAG or something. Until UCIe 2.0, there was no standard definition of the protocol to manage that system. But it goes further than that. It’s also about testability, where you may have a die that fundamentally only has a UCIe interface. How do you manage testability within your system? They defined system capabilities that are outside of the scope of the physical protocol, but specifying how there’s interaction across either the main interface or the side band interface.”
Not everyone is a fan. “There are other ways of addressing many of those same considerations that have some tradeoffs in terms of overhead and invasiveness relative to the functionality you’re trying to get,” says Alon. “Today, everyone has different ways of doing these things, and they are all optimized for slightly different use cases.”
But standardization offers other advantages. “UCIe 2.0 is thinking ahead, as far as the management layer, offering a standardized way to manage chiplets and look at things like the DFx, so test and debug,” says Siemens’ Rodriguez. “This opens an opportunity for, not just the chiplet vendors to develop software, but for EDA vendors to develop additional tools for testing these chiplets. I don’t think companies will be able to just slap it onto the package. They will do testing of these chiplets standalone and with UCIe 2.0. The management and the DFx additions allow for companies to be able to do that in a standard way.”
All parts of the development chain need to be considered. “The advanced manageability features and protocols enable precise memory access and efficient communication within multi-chiplet systems,” says McKenzie Ross, vice president of marketing for SmartDV. “By addressing the complexities of system integration and lifecycle management, UCIe 2.0 simplifies the adoption of chiplet-based architectures. As it establishes itself as the emerging standard for logic chiplets, thorough verification becomes imperative to ensure compliance and reliability.”
The promise of plug-and-play chiplets
Today, chiplets remain on the cutting edge, available to only a few that can afford the costs. “Over the past year, we have only seen two or three announcements of chiplets that you could potentially buy off the shelves and include in your package, along with your own custom logic,” says Rodriguez. “We see projects taping out in two years that would adopt UCIe 2.0. The whole idea is that you should be able to reduce the complexity of your own projects and buy off-the-shelf chiplets for things like adding an FPGA, adding AI accelerators, adding memory into your package, and then only worry about integration and managing those different templates. But it is early to make that call.”
There also has to be a compelling reason to do it. “The dirty secret of multi-die is that it’s additional complexity,” says Posner. “The value of multi-die is so high that companies are willing to take on that complexity to solve a number of issues. It could be reticle limits that they’re hitting. It could be that they want to do compute scaling. They are willing to take on this additional complexity. Our goal is to continually evolve our deliverables to enable that in a more seamless fashion. It’s not just an IP at that point. It’s got to be tooling, ecosystem, flows, reference designs, all the way through to potential references for that whole chiplet.”
While UCIe tackles how two dies communicate, other issues remain. “Defining the interconnect is attempting to put the cart before the horse,” says Alon. “Even when we solve that problem in its entirety, it still will not necessarily give us plug-and-play chiplets. You’re not going to get plug-and-play and interoperability at the chiplet level that is independent of the interfaces.”
Issues exist at multiple levels. “With advanced packaging, like HBM, it really can work,” says Johal. “It’s a simpler channel because it’s only two millimeters on the interconnect side. This is where the real world is in terms of high-performance data center guys. For them, cost doesn’t matter. Even though it’s easier to achieve interoperability with advanced packaging devices, people can’t really use them in the commercial market. It’s not as easy as buying a PHY from someone and then, boom, I put my chip together, and I’ll be able to do a chiplet that people can buy. There are huge issues with packaging as well as interoperability.”
Complexity is present at every stage. “There is the physical definition of how the chips are going to interconnect, where the TSVs are, and all these physical packaging issues that people are trying to solve,” says Mao Wang, senior director of product management at QuickLogic. “There’s also the logical interconnection between the chiplets. If you have a chiplet from Vendor A and a chiplet from Vendor B, how do you ensure these two can communicate? Using an FPGA-based chiplet solves that problem. Now you have the ability to define whatever protocol you want to have above the UCIe physical layer. We’ll be able to communicate no matter how you want to send your data from one chiplet to the other. This is important, especially as we’re looking at a more mainstream market that would benefit from chiplets.”
Someone has to define what the chiplets look like physically. “OCP has the open chiplet economy effort and is trying to define these chiplet sockets,” says Alon. “The other event that has drawn a lot of attention was the Notice of Funding Opportunity that was put out by National Advanced Packaging, funded by the U.S. CHIPS Act. A component of that is to define specific chiplets. They want to know what those are, how they fit together, what they do. In your system design, what third-party devices could you plug in for those specific places. The attractiveness of the plug-and-play vision is strong enough that there’s a reasonable amount of discussion and effort around trying to make it happen.”
Cost remains a big barrier. “There’s another standard called bunch of wires (BoW), which can target standard packaging and that’s the easiest way to get started with chiplets,” says Johal. “They can drive a channel length of about 10mm to 15mm without termination, and up to 25mm with termination. If you take a 64-bit link, that is a point-to-point connection. You need 64 receiver links, and you need 64 TX. It’s a whole host of pins. And if you have 130mm pitch, you’re looking at 6mm2 per link, and a link has two of these. It’s not viable from a cost standpoint. The other challenge is that for that length to work, the signal integrity and power integrity becomes very problematic. If you have a long link, which everybody likes — even with a PHY from the same vendor, but in different nodes — to get that to work with those long reaches, with different materials, it’s a mess.”
Partnerships are forming to help solve some of these issues. “Organic substrates are more unified, because it is a more mature technology, but it’s not applicable to a lot of the high-performance compute scaling,” says Posner. “It doesn’t offer the bandwidth density. It’s very focused on a closed ecosystem, because everyone in that ecosystem has to be aligned for it all to mix-and-match. That situation exists for automotive. These mini-ecosystems are building where the supply chain view is enclosed. The barrier to multi-die is lowering, and that’s because of a maturing of the technology, a maturing of the tools, ecosystem, IP that’s available, but also the abundance now of expertise and references. We will get to a point where best practices will come into place.”
Other contenders
Closed ecosystems also allow for more specialized solutions. “UCIe is well-suited to many chiplet applications, although some applications with asymmetrical traffic such as sensors and memory may require more specialized interconnect schemes,” says Kevin Donnelly, vice president of strategic marketing at Eliyan. “A standards-based approach will be key to enabling an open chiplet economy and marketplace in the future. Since today much of the chiplet implementation is being done in a captive fashion by the large early adopters, more specialized and optimized interconnects will likely continue to be used in the highest volume applications.”
While UCIe may address the needs of the existing user base, it does not cover everything. “UCIe does not address all of the needs of all markets,” says Siemens’ Rodriguez. “We do see other competing solutions. For example, Bunch of Wires is currently working on defining a memory specific mode, which UCIe is not addressing. Bunch of Wires is a lot more customizable and serves the needs of captive chiplets, but UCIe is way ahead in terms of fostering interoperability for an open chiplet marketplace. If you need different bandwidth requirements, or asymmetric bandwidth requirements, then UCIe does not address these problems.”
UCIe is attempting to be ahead of the needs of the market. “It was released early, compared to our experience with other standards like PCI Express,” adds Rodriguez. “They released a final version of UCIe 2.0, and we’re just starting to see the first few projects implementing it. With PCI Express, IP companies will start implementing IP from a 0.5 revision of the spec. UCIe seems to have taken the approach of creating the spec and releasing it before adoption.”
There is a danger that it is not addressing the right needs. “I believe that chiplets will end up with sockets and people defining them very carefully, specifically for their own individual use cases,” says Alon. “It is somewhat unlikely that anything that sophisticated is really needed in the vast majority of cases. For most cases, the extra overhead is a headache. I’m saying this more about the system management, boot up, a few 100 pages of the spec.”
Missing the point
Will UCIe enable an open chiplet marketplace, or is it only addressing the needs of the existing adopters? That is a question about the advantages that chiplets may present to the mainstream market. “The whole point of this chiplet concept is that medium-sized companies, which are able to use chiplets that have been proven, can reduce their costs,” says QuickLogic’s Wang. “They want to create something that is unique without having to build an entire ASIC from scratch, which would take them much longer with higher development costs.”
Costs remain the big barrier. “For startups, from a technological perspective and end-volume cost perspective, it might make sense for them to be in a chiplet style of design,” says Alon. “That does mean they need multiple mask sets, multiple tape-outs. Compare the initial NRE of that to a larger monolithic chip in an advanced node, and it is not a simple tradeoff. There are cases where the NRE of getting your first product could be lower by sticking to a monolithic solution. It’s a complex dance. This is true of many things in engineering. The thing you would do in steady state, once you’ve already got a large enough market and a large enough business may be quite different than what you have to do to enter.”
That likely will change in the future, but not today. “If you are a medium-sized company and you’re looking for chiplets from two or three vendors, you probably don’t want to go into super-advanced packaging,” says Wang. “That is going to eat up most of your costs and you might as well just go build an ASIC.”
Related Reading
Strain, Stress In Advanced Packages Drives New Design Approaches
Heterogenous integration is pushing chip and package designers to consider multi-physics effects as early as the initial architectural planning stage; new tools may be needed.
Top-Down Vs. Bottom-Up Chiplet Design
Third-party chiplets are hitting the market as chiplet models evolve. Who’s calling the shots isn’t clear yet.
Leave a Reply