UCIe 1.1 Specs Announced for Chiplet Future

2
UCIe A Bump Map Optimization
UCIe A Bump Map Optimization

During the week of FMS 2023, we had a new UCIe 1.1 spec arrive for the chiplet future. This new spec is bringing a number of new capabilities to future processors. Although it is a relatively small update to UCIe 1.0, it is the result of feedback on what is needed to get UCIe 1.1 implemented in more places.

UCIe 1.1 Specs Announced for Chiplet Future

UCIe 1.1 has four main enhancements. First, is that the automotive segment shared an interest in UCIe with different requirements. Second, there are new streaming protocols. Third, there are new packaging layouts for lower-cost connectivity. Finally, UCIe is moving into a phase where they are looking at compliance testing to support interoperable chiplets.

UCIe 1.1 Summary
UCIe 1.1 Summary

On the automotive side, there are were a few requirements. Instead of re-typing what is on the slide, here is the first part:

UCIe 1.1 Automotive Enhancments 1
UCIe 1.1 Automotive Enhancements 1

The automotive segment had requirements for being able to do things like test and maintain links, so those were added.

UCIe 1.1 Automotive Enhancments 2
UCIe 1.1 Automotive Enhancements 2

On the streaming protocols, this is one where as organizations joined the UCIe consortium, requirements expanded the spec. UCIe 1.1 expands the streaming protocols to cover more types of chiplets and IP.

UCIe 1.1 Streaming Protocols
UCIe 1.1 Streaming Protocols

Here we can see the steaming protocol flit formats and the big change ont he streaming side.

UCIe 1.1 Streaming Protocols Flit Formats
UCIe 1.1 Streaming Protocols Flit Formats

The third major change is also around new bump map configurations for UCIe. To have a set of interoperable chiplets, all of the I/O pins need to be standardized. Think of this, in many ways, like USB. If everyone had their own I/O layout, then it would not be easy to plug things in. Now, instead of just having a USB Type-A connector, the industry is looking at adding other connectors like Type-C following the USB analogy. In UCIe terminology, that is 16-column and 8-column configurations.

UCIe A Bump Map Optimization
UCIe A Bump Map Optimization

Part of the reason we have these different layouts is efficiency. The original UCIe spec covered a wide range of use cases, but depending on the packaging technology, the new versions can be more or less efficient.

UCIe A Area Column Type Plot
UCIe A Area Column Type Plot

Here is what they look like. The common thread is the 388.8um shoreline.

UCIe A Bump Map Illustration
UCIe A Bump Map Illustration

The other change is the ability to use x32 instead of x64 for smaller links. This does not cut the link by 50%, but it saves a large amount of cost for those applications where perhaps there is a greater I/O count needed, but not necessarily as much bandwidth per link.

UCIe 1.1 Reduced Width
UCIe 1.1 Reduced Width

From a compliance standpoint, there is a question of how these chiplets will be tested. After all, the idea is to create a world where chip designers can pick IP from different companies and fabs and then integrate it. As a result, knowing if the UCIe spec is met is an important step. The current thinking is that it will use a golden die packaged with the chiplet being tested.

UCIe 1.1 Compliance Setup
UCIe 1.1 Compliance Setup

Here are some of the things being considered for the compliance program.

UCIe 1.1 Compliance Summary
UCIe 1.1 Compliance Summary

The fact that how to do compliance testing is being refined tells us a bit about how far some companies are in the process of implementing UCIe.

Final Words

UCIe is going to be huge in the future, just like CXL. Our guess is that looking back in three years UCIe is going to be one of the foundational technologies in chipmaking. The fact that it is everywhere means that it is an important technology to track, even if it is not everywhere today. Further, UCIe 1.1 spec changes many not be huge, but they are a refinement due to very different sets of folks joining the consortium and providing input.

2 COMMENTS

  1. I’m no expert in the matter. However one can note that end-to-end encryption in CXL only came with version 2.0 of the standard. CXL uses AES-GCM. In the case of UCIe, the end points are chiplets. Is end-to-end encryption a (necessary) feature between chiplets? If so, what will be the standard(s)? Implementing encryption requires keys, IVs. How will they be managed, protected, rolled? Will these processes leave data bread crumbs, e.g. in register(s)? Do we already have heavyweight security experts playing vandals and looking at breaking CXL and UCIe for data leaks? Or will we “discover” exploits after the fact, like what it is happening with speculative side-channel attacks for the last 5 years in CPUs or ISA bugs, with performance degradation due to mitigations?

  2. You need a short explanation of what UCI and UCIe is, or a link to an earlier article explaining the concept. It is not hard to work out what UCI is (a standard for chiplets) but with no knowledge of the acronym you start out in the dark at the beginning of the article.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.