# Why Chip Designers Are Embracing Multi-Die Simulation

An episode of [The Hardware Podcast with Fexingo: Chips, Devices, and Electronics Engineering Conversations](https://invisiblenetwork.ai/podcast/1896799982), 13 Jun 2026, 7:19.

Audio: https://audio.fexingo.com/business/the-hardware-podcast/episode-0048.mp3

Episode 48 dives into the growing complexity of simulating multi-die chip designs, where chiplets and advanced packaging create new verification challenges. Lucas and Luna explore how EDA tools are evolving to handle system-level thermal, power, and signal integrity issues that single-die designs never faced. With specific data on simulation time blow-ups and real examples from the latest design flows, they examine why multi-die simulation is becoming a bottleneck—and the techniques engineers are using to break through. A must-hear for anyone following the shift to heterogeneous integration. #ChipDesign #MultiDie #Simulation #EDA #AdvancedPackaging #Chiplets #SignalIntegrity #ThermalManagement #PowerIntegrity #Verification #HeterogeneousIntegration #Semiconductor #Technology #HardwarePodcast #FexingoBusiness #BusinessPodcast #ElectronicsEngineering #DesignTools Keep every episode free: buymeacoffee.com/fexingo

## Transcript

Lucas: So you take a modern high-performance chip — say, a data-center CPU or an AI accelerator — and it's not a single monolithic die anymore. It's four, six, maybe a dozen chiplets all talking to each other through a silicon interposer or a bridge. The design complexity doesn't just add up; it multiplies. And the simulation problem is starting to scare people.
Luna: Because you're not simulating one chip — you're simulating a whole system on a package. And the interactions between dies are where the nasty surprises hide.
Lucas: Exactly. I was talking to a verification engineer at a major EDA company last week, and he said a full multi-die simulation of a 12-chiplet design can take over 40 hours on a dedicated server farm. That's for a single run. If you're doing iterative design — which everyone is — you're looking at weeks of simulation time.
Luna: And that's just electrical. You've also got thermal, mechanical stress, power delivery — all coupled across the dies. It's a multi-physics nightmare.
Lucas: Right. Let's break that down. On a single monolithic die, you simulate the transistors, the interconnects, the clock tree, and you're mostly done. The boundary conditions are clean — power comes in from the bumps, heat goes out through the package. But with chiplets, each die has its own power domain, its own thermal profile, and they interact through the interposer.
Luna: So the thermal profile of one die affects the performance of its neighbor. And that's a feedback loop that's hard to model.
Lucas: Yes. And the EDA tools are catching up, but it's not trivial. Traditionally, you'd simulate each die separately, then stitch the results together. That's called 'divide and conquer,' and it's what most teams do today. But the problem is that the stitching loses the coupling effects — the things that happen when two dies are running at full tilt and the power delivery network sags simultaneously.
Luna: So you get a design that passes all the individual die simulations but fails when you put it together. And that's a very expensive surprise to find at the system-level test stage.
Lucas: Exactly. And we're talking about chips that cost tens of millions to tape out. So the industry is moving toward co-simulation — where you simulate the full system, dies plus interposer, in a single environment. But that pushes the computational load through the roof.
Luna: Because you're modeling billions of transistors, plus the RDL, the microbumps, the TSVs in the interposer — all at once. It's a data problem.
Lucas: It really is. One thing that's helping is what's called 'reduced-order modeling.' Instead of simulating every transistor in the power grid, you create a simplified model that captures the key impedance characteristics. That can cut simulation time by orders of magnitude, but it requires careful validation.
Luna: And that validation itself requires simulation, so you're still spending compute. But at least it's a one-time cost per design.
Lucas: Yeah. And the tool vendors are also working on hardware acceleration — using GPUs or FPGAs to parallelize the simulation. I've seen demos where a 48-hour simulation is cut to 6 hours using a cluster of A100s. But that's expensive hardware.
Luna: So the cost shifts from engineering hours to compute hours. But at least you can rent that compute on the cloud. It's not like you have to buy the cluster.
Lucas: Right. And some companies are doing that. But there's another angle: the simulation itself is only as good as the models you feed it. If your chiplet model is too abstract, you miss real effects. If it's too detailed, you can't simulate it in a reasonable time.
Luna: So it's a modeling trade-off. And that's where the expertise of the design team really matters — knowing what to simplify and what to keep detailed.
Lucas: Exactly. And that's why I think we're going to see more specialization in simulation engineering. It used to be a background role in chip design; now it's becoming a critical path item.
Luna: Yeah, I've noticed job postings for 'multi-die verification' engineers popping up with very specific requirements. It's a new niche.
Lucas: And it's a good one to be in, because the trend toward chiplets isn't slowing down. Every major foundry is investing in advanced packaging — TSMC with CoWoS, Intel with EMIB, Samsung with I-Cube. And with that comes the need for better simulation.
Luna: So if you're a chip designer or a student looking at this field, simulation tools and methodologies are a huge opportunity. And speaking of opportunities, I want to mention something briefly.
Lucas: Go ahead.
Luna: We keep this podcast ad-free and independent — no sponsors, no paid segments. It's just us and the topics we find interesting. And that's possible because of listeners who support us directly. A couple of dollars a month genuinely makes a difference.
Lucas: Yeah, it really does. If you've gotten something out of these episodes — maybe a new insight, a conversation starter, or just a better understanding of the tech world — you can help keep them going. The link is buy me a coffee dot com slash fexingo.
Luna: It's a small thing that adds up. And we appreciate every bit of support. Okay, back to simulation — one more angle I wanted to bring up.
Lucas: What's that?
Luna: The role of machine learning in accelerating simulation. I've seen papers where ML models are trained to predict the outcomes of expensive simulations — like thermal hotspots or IR drop — and then used as surrogate models during design iterations.
Lucas: That's promising. But you have to train those models on a lot of simulation data to begin with. So it's not a free lunch. But once you have a good surrogate, you can explore the design space much faster.
Luna: Exactly. And the ML models can also help with the 'divide and conquer' problem — they can learn the coupling effects between dies and correct the stitched results.
Lucas: So you get the speed of divide and conquer with the accuracy of co-simulation, at least to a first order. That's a neat idea. I wonder how well it works in practice.
Luna: From what I've read, it's still early-stage. But a few EDA startups are betting on it. And the big vendors are integrating ML features into their tools.
Lucas: That's the pattern, isn't it? Startups push the frontier, then the incumbents absorb it. Either way, the simulation problem gets solved a little more each year.
Luna: And the chips keep getting more complex. So maybe we'll never be done — but that's what makes it interesting.
Lucas: Absolutely. Alright, I think that's a good place to wrap. Next episode, we'll talk about something completely different — maybe the role of materials science in next-gen interposers.
Luna: That sounds good. See you then.
Lucas: Thanks for listening.

Shows are listed from Apple Podcasts' charts and directory, and Podcast Index where it is used. Every show and episode belongs to its publisher and plays from the publisher's own feed; this site hosts none of them.