AMD says the UCIe universal chiplet interface will create a whole ecosystem — custom multi-chiplet designs are the future

AMD
(Image credit: AMD)

Several years ago, AMD adopted a multi-chiplet design for its client desktop and data center processors well ahead of its rivals. Back then, it was the only way for AMD to offer products with higher core counts than rival Intel, and now the move is seen as a strategic pivot towards an inevitable multichiplet design methodology. Today, Sam Naffziger, senior vice president and corporate fellow at AMD, thinks about how the Universal Chiplet Interconnect Express (UCIe) specification will create a chiplet ecosystem and enable custom multi-chiplet design.

For modular multichiplet designs, a high-performance, low-latency, and low-power interface is a must. The Infinity Fabric interface enabled AMD to build unique EPYC, Ryzen, and now Instinct MI300-series processors with unrivaled core counts, performance, and feature sets, Naffziger explained in a YouTube video conversation with Mark Papermaster, AMD's chief technology officer.

"The [interface] latency was too high, the power cost was too high, but we had a team of can-do engineers who said, 'I know how to solve that problem,' 'I will deliver a lightweight interface,' 'I will slim this down,' and 'I will eliminate cycles of latency,'" Naffziger said referring to the era when AMD was developing its multi-chiplet 2nd-gen EPYC and Ryzen processors. "If we hit these targets, now we have a multi-die solution that behaves just like a monolithic SoC. We set those targets, and then we oversaw the team's execution to make it happen. It was so transformative."

To a large degree, Infinity Fabric was a savior for AMD when it was introduced. However, since this is a proprietary technology, it cannot be used by third parties. This is where the open UCIe specification for die-to-die interconnects comes into play. The open spec, largely based on Intel's AIB, defines a 32 GT/s 16 to 64 lanes physical layer, protocol stack (CXL.io, CXL.mem, and CXL.cache), software model, and compliance testing procedures. As for performance, the UCIe 1.0 technology enables bandwidth density up to 1.35 TB/s per mm^2 for a common 45-micrometer bump pitch. 

"What we can do [with UCIe] is have a chiplet ecosystem and library, […] UCIe opens up the opportunity for third parties to exploit that [modular design capability]," said Naffziger. "Companies who want to do a custom platform and leverage everything else can just do one little chiplet and bolt it up. So, the opportunities are endless. I mean this; we're going to see much more of this proliferating in the industry, but it does require standards and carefully thought-through design platform capability." 

While AMD was part of the group that developed the UCIe specification, whether the company plans to build UCIe-compatible chiplets remains to be seen. 

Anton Shilov
Freelance News Writer

Anton Shilov is a Freelance News Writer at Tom’s Hardware US. Over the past couple of decades, he has covered everything from CPUs and GPUs to supercomputers and from modern process technologies and latest fab tools to high-tech industry trends.

  • Notton
    I was wondering when we would hear more about UCIe. It's been some 1~2 years since I last heard any mention of it.

    From the sounds of it, I am guessing it's ready, but AMD doesn't want to produce anything without demand?
    Reply
  • rluker5
    It is nice that AMD is getting on the Intel version of chiplets bandwagon. Open source is good and so is wide compatibility.

    Makes you wonder if someday you could get a mix and match of different vendor chiplets on a package. Like a phone SOC with an Nvidia iGPU chiplet, or an Intel CPU chiplet with some Threadripper class I/O die.
    Reply
  • TechLurker
    Given it's partly based on Intel IP made open source, I wonder if this is also part of Intel's pivot to opening their fabs; and if it's also compatible with their Foveros tech.
    Reply
  • bit_user
    Notton said:
    I was wondering when we would hear more about UCIe. It's been some 1~2 years since I last heard any mention of it.
    Several months ago, ARM announced plans to develop and sell its IP on chiplets, instead of designs that their customers must fab as part of their own SoC.

    In this video Jim Keller is extolling the virtues of a chiplet ecosystem, although speaking to a friendly audience (TSMC):
    o70yKYWgtVIView: https://www.youtube.com/watch?v=o70yKYWgtVI
    Notton said:
    From the sounds of it, I am guessing it's ready, but AMD doesn't want to produce anything without demand?
    We have no idea what kind of discussions they're having with big customers, like Google or Microsoft. Maybe they're already planning products with chiplet-level integration.
    Reply
  • bit_user
    rluker5 said:
    It is nice that AMD is getting on the Intel version of chiplets bandwagon. Open source is good and so is wide compatibility.
    LOL, wut? That's some revisionist history!

    AMD co-founded the UCIe consortium, along with Intel and ARM. This article doesn't indicate a shift in any public position on the matter.
    https://www.anandtech.com/show/17288/universal-chiplet-interconnect-express-ucie-announced-setting-standards-for-the-chiplet-ecosystem
    rluker5 said:
    Makes you wonder if someday you could get a mix and match of different vendor chiplets on a package. Like a phone SOC with an Nvidia iGPU chiplet, or an Intel CPU chiplet with some Threadripper class I/O die.
    Sort of like this Kaby Lake-G?
    https://www.tomshardware.com/news/intel-discontinue-kaby-lake-g-amd-graphics,40577.html
    ...except that required close partnership between the two companies.

    In a UCIe world, the main catch is just that the standard is primarily an electro-mechanical specification. It includes several protocols, but leaves the door wide open for proprietary protocols. So, the main question would be whether the chiplets you want to integrate all support compatible protocols. If so, then you should just need some degree of software/driver-level support and you should be good to go.
    Reply
  • rluker5
    bit_user said:
    LOL, wut? That's some revisionist history!

    AMD co-founded the UCIe consortium, along with Intel and ARM. This article doesn't indicate a shift in any public position on the matter.
    https://www.anandtech.com/show/17288/universal-chiplet-interconnect-express-ucie-announced-setting-standards-for-the-chiplet-ecosystem
    From the source article of this comment thread: "The open spec, largely based on Intel's AIB"

    From this previous article: https://www.tomshardware.com/news/new-ucie-chiplet-standard-supported-by-intel-amd-and-arm "Intel had previously used two interface IP blocks for EMIB; the Advanced Interconnect Bus (AIB) and UIB. Intel donated AIB as an open-source royalty-free standard in a previous attempt to foster a standardized chiplet ecosystem, but that didn't gain much industry traction. However, UCIe and AIB are not inherently interoperable (special subset designs can enable the use of both), so while Intel will continue to support current AIB implementations fully, it will stop all further development and migrate to UCIe."

    From this article: https://www.tomshardware.com/news/intel-flashes-worlds-first-ucie-connected-chiplet-based-cpu "Intel CEO Pat Gelsinger displayed Pike Creek, the world’s first UCIe-connected chiplet-based test chip, here at Innovation 2023, marking the first public display of working UCIe-enabled silicon. The test chip features an Intel UCIe IP chiplet fabbed on its own Intel 3 process node paired with a Synopsys UCIe IP chip fabbed on the leading-edge TSMC N3E node. The two chiplets communicate via Intel’s EMIB interface."

    And finally back to the source article: "While AMD was part of the group that developed the UCIe specification, whether the company plans to build UCIe-compatible chiplets remains to be seen."

    Hopefully AMD will support this open source protocol in actions not just words and increase chiplet compatibility instead of sticking with their closed, proprietary infinity fabric. More words in favor of support are hopefully an indication that they may adopt some form of it.
    bit_user said:
    Sort of like this Kaby Lake-G?
    https://www.tomshardware.com/news/intel-discontinue-kaby-lake-g-amd-graphics,40577.html
    ...except that required close partnership between the two companies.

    In a UCIe world, the main catch is just that the standard is primarily an electro-mechanical specification. It includes several protocols, but leaves the door wide open for proprietary protocols. So, the main question would be whether the chiplets you want to integrate all support compatible protocols. If so, then you should just need some degree of software/driver-level support and you should be good to go.
    Hopefully so. More options are definitely better. It's a shame those NUCs that had that combo were so expensive.
    Reply
  • bit_user
    rluker5 said:
    From the source article of this comment thread: "The open spec, largely based on Intel's AIB"
    None of that supports your implication that AMD wasn't on the UCIe bandwagon. They co-founded the UCIe Consortium with Intel and ARM! How can they not be on the bandwagon of a consortium they co-founded??

    None of your supporting points show AMD at odds with UCIe and I will further point out that you did not show an Intel product using UCIe. Intel showed a test chip, which they had incentive to do for the sake of their fabs - an incentive AMD doesn't share. So, it means nothing that AMD didn't also show a test chip.

    rluker5 said:
    "While AMD was part of the group that developed the UCIe specification, whether the company plans to build UCIe-compatible chiplets remains to be seen."
    This is just the author making sure to establish the facts. They're not saying we have any reason to doubt AMD will make any UCIe-based products.

    rluker5 said:
    Hopefully AMD will support this open source protocol in actions
    It's not a protocol.

    rluker5 said:
    not just words and increase chiplet compatibility instead of sticking with their closed, proprietary infinity fabric.
    Words do matter, though. It's messaging perhaps to entice partners into discussions about chiplet-level integration.

    To what end do you care if they adopt UCIe? Whether they internally use it in their products is of no consequence, if they neither support 3rd party chiplets or sell their chiplets to others! These are the key developments, with UCIe merely being an enabling technology.
    Reply
  • rluker5
    bit_user said:
    None of that supports your implication that AMD wasn't on the UCIe bandwagon. They co-founded the UCIe Consortium with Intel and ARM! How can they not be on the bandwagon of a consortium they co-founded??

    None of your supporting points show AMD at odds with UCIe and I will further point out that you did not show an Intel product using UCIe. Intel showed a test chip, which they had incentive to do for the sake of their fabs - an incentive AMD doesn't share. So, it means nothing that AMD didn't also show a test chip.


    This is just the author making sure to establish the facts. They're not saying we have any reason to doubt AMD will make any UCIe-based products.


    It's not a protocol.


    Words do matter, though. It's messaging perhaps to entice partners into discussions about chiplet-level integration.

    To what end do you care if they adopt UCIe? Whether they internally use it in their products is of no consequence, if they neither support 3rd party chiplets or sell their chiplets to others! These are the key developments, with UCIe merely being an enabling technology.
    I was hoping AMD would do more than just provide lip service to support the standard while staying with their competing closed source proprietary model. At least Nvidia is honest about their stance.
    Reply
  • bit_user
    rluker5 said:
    I was hoping AMD would do more than just provide lip service to support the standard
    I doubt they're going to undertake the trouble & cost of engineering UCIe into their products, without someone who either wants to buy their chiplets or integrate a 3rd party chiplet in their products. Their statement should be seen as a pitch to those who are so inclined. Companies don't usually issue public statements for no reason...

    rluker5 said:
    while staying with their competing closed source proprietary model.
    Not closed-source. You're talking about a proprietary interconnect vs. open standard. It has nothing to do with open source. And using UCIe doesn't somehow magically make a product better.

    As an end user, we neither know nor care what's going on inside the package. IMO, their implementation of UCIe (or lack thereof) is driven entirely by business-level concerns and priorities. Same with Intel. If there are bushiness opportunities motivating it, I'm confident AMD will do so.

    rluker5 said:
    At least Nvidia is honest about their stance.
    This is not about honesty, hypocrisy, or anything like that. Also, I find it troubling that you seem to be moralizing this issue. This is a technical standard, not a moral issue.

    Also, just because a company implements UCIe doesn't mean they have to sell their chiplets on the open market or support integration with any given 3rd party chiplet someone else might have. These are business-level issues and the technology is merely a way to enable that.
    Reply
  • rluker5
    You can have both open source and open standard: https://www.tomshardware.com/news/intel-joins-chips-alliance-to-foster-chiplet-ecosystem
    Intel wants to make using chiplets easier for everyone. Has AMD contributed anything other than going to some meetings for photo ops? AMD doesn't have to adopt a standard to help the little guy, but if their only contribution is pretending they doing their share in bringing this benevolent advancement to fruition, that's just phony.

    I don't know that is all that AMD has done, that is just all I've heard that they've done regarding UCIe. I'm sure we will get more articles about AMD's "support" of it in the future as well.
    Reply