SemiWiki.com - Podcast EP315: The Journey to Multi-Die and Chiplet Design with Robert Kruger of Synopsys

Episode Date: October 31, 2025

Daniel is joined by Robert Kruger, product management director at Synopsys, where he oversees IP solutions for multi-die designs, including 2D, 3D, and 3.5D topologies. Throughout his career, Robert has held key roles in product marketing, business development, and roadmap planning at leading companies such as Intel, Broadcom,… Read More

Hello, my name is Daniel Nenny, founder of semi-wiki, the open forum for semiconductor professionals. Welcome to the Semiconductor Insider's podcast series. I guest today is Robert Kruger, Product Management Director at Synopsis, where he oversees IP solutions for multi-ddyed designs, including 2D, 3D, and 3-5-D topologies. Throughout his career, Robert has held key roles in product marketing, business. development and roadmap planning at leading companies such as Intel, broadcom, Nokia, and Altera. He brings extensive expertise in semiconductor technologies, including ASICs and FPGA products, as well as deep knowledge of specialized requirements across various

sectors, including wireless infrastructure, military, automotive, industrial, and data center markets. Welcome to the podcast, Rob. Thanks so much, Daniel. Pleasure to be here, and I look forward to our discussion. Yeah, you have an impressive resume, Rob. What brought you to synopsis? That's a very good question, Daniel.

So I've been working in the industry for a while. I was working at jobs at Broadcom and Intel that both got me exposed to the idea and concepts of chiplets, as far as integrating analog at one point, and then later Ethernet, analog, and other protocols. And I saw this opportunity of this job at a synopsis to work on strategy for chiplets going forward. And really the momentum I saw growing when I joined here a little over a year ago. It's just tremendous. And it's really gotten me more excited than I can say I've been in the last 10 years. It's just so exciting, the pace of innovation in packaging and IPs and how you put these chiplets together.

That really, for me, it's a way to come into a great company, a large company, so an office leader in the IP industry, but also work in this industry and have a chance to make an impact on industry through this adoption of chiplets going forward. Yeah, I agree with you completely. So first, let's find out how synopsis defines the term chiplets. So, chiplets, to me, it's a single function device. So you have a one chipplet will generally be one function. It'll have a way to connect to other chiplets in the system. Those other chiplets in the system, you know, have one or more other functions.

So you can have compute, dyes, I.O. dyes. You can have a system management die, different flavors. Those chiplets can each be on different process nodes. They don't have to be the same. They could be the same, but they could be heterogeneous. And the idea there is you use the most advanced process technologies for the compute chiplets, for example. And maybe you have other triplets where you're doing more I.O. and analog functions,

you might do those on an older node chiplet. And it gives you that ability to mix and match technologies and functionalities. But a chiplet as a core, it's a single-use piece of silicon that can be reused in one or more projects. So you can have one chiplet being used in several multi-dicycle. systems. Right. And you use the term multi-dii designs. How is it different from chiplets? Yeah. So I just look at the chip-let as the individual functions. So you're designing this piece of functionality that fits into a multi-dye system. The multi-dye system comprises multiple

chiplets. And then you're worried about how you're connecting those chiplets together, how you're doing verification of that complete multi-dye designs and looking at things like multi-physics analysis and power not just of each individual chipplet, but also the system and hotspots between the chiplets. So it's a little bit more comprehensive when you get to that multi-dye aspect and creating a total system as opposed to an individual chiplet. Right.

So can you briefly describe the multi-dye market today? Sure. So the multi-dye market really is driven by AI and data centers right now. That is the bulk of where things have been driven and where the start really of this multi-dye chiplet architecture has come about. The next largest market that we see and also I've seen in industry ports is automotive market. And then there's also chiplets in things like physical AI, so robotics, for example. And the motivations for chiplets in each one of those markets is a bit different. The other thing I see is today, most of the designs in the market are captive designs. So that's one vendor is designing all the chiplets. They're doing all the specification of the chiplets. And maybe you'll have vendors that are supplying IP or even subsystems like grips of IP

could all go all the way to GDS2 or even KGDs, a known good dye, which is a tested dye that you can deliver to the main aggregator. There is this vision out there of an open chiplet marketplace where different vendors supply ready-made chiplets, but in my estimation, that's probably five to ten years away. And really is a few headwinds there to the open market. One is there's a lot of fragmentation requirements, just an I.O. Chiplet example, so you can have things like 224 gig, Ethernet, UAL, PC Express 7 or 6, and different combinations of those. There's lots of fragmentation. And the fragmentation, one, makes it difficult to have sufficient monetization for an individual chiplet if you were going to be a third party trying to sell it to multiple parties. There's so many needs out there. You could build a superset chiplet, but that's at the expensive cost. form factor and power so those may not be acceptable tradeoffs and it's going to hinder that the second headwind i'd say is related to standards the standards are evolving and they're great

they're coming you know things like the uceae consortium keeps adding different standards about system management as things like the arm cSA but we still need to go further so inside a single multi-dye design you can anywhere from a handful of shiplets to near 50 and all these These chiplets must interact together cohesively, but also meet physical form factor constraints, which in itself can be very difficult. Telemetry needs, security needs, test needs, and then test before, package assembly, and after, and then managing things like Bringup. And we are making great progress along this, but there's still a lot of variation and a lot of variation of needs that need to be addressed. And so customers are coming up with their own solutions in these captive environments right now. Right.

But, you know, you mentioned AI and HPC and automotive. Are automotive companies adopting the architecture for the same reason as AI and HPC? To me, it's a little bit different. So looking at the automotive companies and also these consortiums, like there's IMEC and Astra from Japan, IMEC in Europe, and they have different needs. So in automotive markets, you're kind of looking at instead of going to, data, market, you might be going to bigger and bigger chiplets to get more compute. In automotive market, you don't want big dye. So you might break up a single monolithic dye into several smaller chiplets. And that helps with defect density and getting to a better yield and then

better reliability as well. And then you also meet, they're looking at things like having a base die with a certain set of functionality. And then to support other markets, like maybe going from a low-end car to a mid-range to a high-end, they might add additional chiplets to support different functionality. So maybe adding in an additional I.O. Chiplet or additional entertainment IVI chiplet or adding in AI chiplets, for example, to get more performance and supporting this concept of a software-defined vehicle by changing software, but also adding hardware as needed through chiplets. And you can do that much faster. Once you have a collection of chiplets, you can have different combinations and create product variants very quickly.

So that's kind of the concept that's being used in automotive as opposed to a data center where it's more about trying to get to, you know, meeting these growing needs of computers and AI and getting the compute die, getting larger and larger, almost the full reticle, and then disaggregating I.O. and memory in order to get, you know, feed those compute resources with enough memory and enough I.O. So kind of a different strategy for each of those markets. Yeah, that makes sense. So in your view, where does. the journey to chiplit design start? So I think as far as where it starts, you start with partitioning and design, figuring out which code goes in which chiplet. It's a first state. And you want to look at things like power, latency, even physical form factors. You may use some modeling tools to do trade-off analysis on the petitions and looking at power

and latency effects. Then you might start looking at die-to-die interfaces. And so you have UCIE, which is pretty much a de facto standard now, but it's not so simple as just saying UCIE. You need to decide which UCIE variant, which line rate, how many channels to meet your application needs and fit into an available beachfront. You might take into consideration whether you're using advanced packaging or interposed of designs. And it's kind of an iterative process going through this top-level design of triplet architecture, figuring out, you know, you go through one step, you get to the next. you might have to circle back because maybe some decision you made changes the previous decisions. And you have this iterative process to get to a working chiplet design over time.

And then thinking about things like security, authentication. Now you have multiple chiplets from different boundaries even. You want to authenticate and maybe a third-party OSAT, you may want to have authentication of the chiplets as part of the security features. And then looking at, do you have to have key management among the chiplets for encryption services? And you need to look at reliability and telemetry requirements, especially in data centers. They have strict requirements on RAS and how do you meet those for your chiplet and then working inside this larger data center environments. And then looking at packaging. So, you know, the goal usually is to have the lowest cost package you can, but you might start off with a substrate-based design, but then you may be pushed into advanced packaging where you use interposers with, you know, higher routing densities.

So they can have more bumps and more interconnect to do more advanced integration. And then finally, looking how do you develop software ahead of selecting availability? Right. And how do IP subsystems contribute to the functionality and efficiency of chiplet designs? That's a very good question. So, yeah, we can deliver IP and we do deliver IP to customers that are building chiplets themselves, so building up these IPs into from IPs into chiplets. But you can also get higher level deliverable. So moving to a higher level of abstraction, you might have an IP subsystem where that IP subsystems may include multiple IPs. So it could be protocols, like I'll just use an example of PC Express and Ethernet on one chiplet. Then you may add in to those each of those subsystems, silicon lifecycle management features.

So things to monitor the certies and maybe even do a test and repair. You might add test features, so higher-go-test, so a chiplet, especially when you have these 50 chiplets in a pack, How do you test each one? So you add test features to the subsystems and the security features into a single deliverables. And that's really adding a lot of value. To do that yourself, you're going to use a lot more resources and probably add more risks, as opposed to getting a subsystem where these different components such as the protocol, the test features, lifecycle management are built together, delivered as almost like an IP deliverable,

but also with a whole verification environment, so you can take that system and be ready to integrate it into your larger system. So can you describe the anatomy of an IP subsystem? Yeah, so again, I might repeat myself a little bit. So an IP subsystem is going to have the IPs, the protocols. It will have things like silicon lifecycle management features. It'll have test features. That could be test for testing the template functionality or even external tests.

We have an external RAM test that can be part of the solution if you were doing an LPDR interface, for example. You could add the security feature. So if you have an IDE feature for PCI Express, that would be included as part of the subsystem. And then you might also need in a separate subsystem some security features to set up a secure route of trust to manage keys for that feature. So you have to think about the subsystems, not just alone, but also how they work in the larger system.

And then you'll have different protocols. So again, mixes of protocols. So you could have PCI 6 or 7. You can have UAL, 200 kithernet, and then the encryption services. There could be separate subsystems for UCIE. And there you're looking at the UCIE features itself, plus maybe monitor and testary features. And the idea there is you can have redundant lanes, and we can build that function in so

that if a lane breaks you during assembly, you can recover that or even out in the field. Years down the road, one of the lanes may go bad. You could actually have a redundant lane, and that could be part of the subsystem. And then the hierarchal test servers, again, really important to allow testing, you have to have testing at the probe level of the different non-good die, but also when you're assembled into a chiplet, you need this test features to connect the different chiplets together and test each one individually and in the system. And then finally, the verification environments is just key, having VIP type verification environments, scoreboards and checkers all part of the solution so that you can easily take subsist and deliver to you, put it into your own. verification environment and integrate into your larger system so what challenges are faced in the design implementation of chiplets yeah we could probably spend an entire podcast just on challenges that there's many I'm

gonna hit on a few of the top challenges you know again I as I mentioned before partitioning is a big thing where do you put which feature on which chiplet that's kind of the first step looking at the die-to-dye interface like expand on that some more because you may have a situation you look at the line rate, you could go to faster line rates, but maybe if you have more beachfront, it might be more efficient to do a lower line rate. And you might have a lower power. You have to look at power for a chiplet, but also power per millimeter squared in some cases is important. Making a trade-off there. And then looking at things like security, do you need to authenticate each one? Do you trust that all the chiplets are valid? Or do you need to protect things even against the gray market or from counterfeiting? to put authentication in the chiplet. And then if you have security features, how do you manage the keys? So part of that challenge would be to have a root of trust, either in the primary chiplet or one of the subordinated chiplets, to have those keys managed for different security

services. And then that might be in a multi-tenant environment in a data center as well. And then looking at reliability and telemetry is also a challenge. So you could say you have a couple sensors and a processor, but you really want that processor or running software and being dependent on software and 20,000 chiplets in a system, or do you take more of a hardware-first approach to look at telemetry and aggregation, how you communicate that data up to the rest of the system. And then packaging, just looking at the routing densities that are needed, the cost constraints you have, there's a penalty on delivery time, whether you go for substrates or interposes.

just take longer to go through the manufacturing cycle. But in some cases, you absolutely need it just to get the performance you need, but then you need to align the bumps between the different shiplets, and that makes sure the bump map alignment's correct. And you have a power and grounds and pitches and that the form factors of the different chiplets align,

lots to think about there. And then finally, this is all under the context that when your chip comes back from development, you better be ready with software. And so that kind of leads the need to do upfront software development or actually software hardware code design. And that can be enabled by things like emulation platforms or FPGA prototyping platforms, which is part of our solutions that we talk to customers about. You know, we should definitely do a follow-up podcast on the challenges of design

and implementation. So I'm going to take you up on that. Final question, Rob. What role does synopsis play in facilitating the development of multi-di and chiplet solutions? Very good question. So we've been at this for a while, long before I got to the company. I've been working on things like the 3DIC compiler on how you design the interposers, how do you do tests between the different shiplets. We've developed tools like platform architecture modeling for upfront modeling of IPs. So you're looking at a transactional model to figure out things like latency, throughputs, and making different trade-offs on design partitioning.

And then we have design implementations, of course, everyone else, RTL, development but also now interposer design tools and now including with the ANSIS acquisition multi-physics analysis for the complete multi-dye design so you're looking at the interposal design and how each chiplet can interact with other chiplets in the same system and then a key part of that is the group I'm in is design IP and we're looking at not just the IPs that you need but also the subsystems and working to make these things work cohesively as a system and looking at lifecycle management, design security, so a holistic system level view of chiplets. And then finally, again, the emulation and prototyping is key, really using things like

our Zbio emulation platforms and HAPS prototyping that enable software development to shift left. And really when your chip comes back from the FAB and packaging, you're ready to start bring up and really get to market much quicker than you could have in the past. Thank you, Rob. Great conversation. It's a pleasure to meet you, and I look forward to having you back. Great. I really appreciate the opportunity, Daniel, and I do look forward to can do discussions. That concludes our podcast. Thank you all for listening and have a great day.