Beyond the silo: Managing data at the speed of 3D IC design

Tova (00:07.020): Welcome back to the 3D IC podcast. In this episode, we’ll continue to explore the 3D IC ecosystem, this time from the data management angle. Now, when people think about 3D IC design, they often think about the incredible engineering, multiple dies, interposers, advanced packaging, thermal and mechanical challenges, and all the innovation that goes into making these systems work. But behind all of that is a massive data challenge. Every tool, every simulation, every design change, every verification run creates data. And in 3D IC, that data isn’t just larger in volume, it’s more connected. A change in one part of the design can affect many others, often across different teams and domains. So the question becomes: how do you keep everyone aligned? How do you know which version is correct? How do you make sure the right people have the right information at the right time? And in advanced chip design, the consequences of poor data traceability can be very real, very public, and very expensive. Today we’ll look at what can go wrong when data management breaks down, why 3D IC makes this problem so much harder, and what teams can do to manage design data more effectively. We’ll also talk about IPLM, how it fits alongside PLM, and how the Perforce and Siemens collaboration is helping create more connected workflows for the future.

Vishal Moondhra (Perforce Software) (01:59.431): Yeah.

Tova (02:13.710): For this episode, I’m excited to introduce Vishal Moondhra, VP of Solutions at Perforce Software. Vishal, welcome to the 3D IC podcast.

Vishal Moondhra (Perforce Software) (02:23.330): Thank you for having me.

Tova (02:26.904): So to get an idea of what can happen when the right data management systems are not in place, can you share a real world example of what can go wrong?

Vishal Moondhra (Perforce Software) (02:43.772): Sure, absolutely. So we actually had this incident in our history where there was a major chip product company that realized that they had shipped one of their flagship products with a flaw in it, you know, a bug. And this was a very public company. They had a lot of customers, millions and millions of customers all over the world. And they found out that there was this known security flaw in some variants of their product, right? And on the chip. Not all variants had that same problem. Some of them did, right? And so they did not have the right traceability to identify which of the chips in the field needed the fix and which did not. Now the real problem was that they had a workaround for this security flaw. It was a very public security flaw. But if they applied it to all the variants that they had in the field, then the variants that did not have the flaw would actually slow down and have a performance issue. So this was a big problem. So they had to find out and actually try to only apply the workaround to a selective few variants in the field, but they did not know which ones. So they ended up having to apply the workaround to all the variants in the field, which was a huge problem.

Tova (03:50.697): Wow. Mm-hmm.

Vishal Moondhra (Perforce Software) (04:11.044): This resulted in a major public relations scandal, you know, multi-billion dollar loss to their market cap, you know, there was even a VP that got fired over this, et cetera, right? So this was a public scandal that blew up in their face. And this was the lack of traceability that we talk about, which can have very serious consequences given the scale of the problem, right? And so this company then sought out a better way to do traceability of what exactly they were taping out into a chip, right? What were the exact contents of what they were taping out. And so they approached us and that’s how our relationship began with them.

Tova (04:47.384): Wow, so that really shows how a data issue can become a business issue. It’s not just about files being hard to find, it’s decisions being made without full visibility into what has changed, you know, which versions are affected. So most companies may not be faced with problems on this scale, but data management can still be quite a challenge. Can you paint a picture of what the data landscape looks like inside a typical chip company working on 3D IC?

Vishal Moondhra (Perforce Software) (05:16.376): Sure. Yeah, so you’re right. I mean, this was definitely a pretty extreme example, but there’s small and big examples throughout the entire chip and 3D IC workflow that do get impacted, right? So for example, when we do chip design, as we go from architecture to RTL all the way through back end and tape out, there are many, many tools that we use to work on this design. And each of these tools tends to build a mini database of its workflow results, activities, you know, and so on. Right. So these mini databases as I call them, they are attached to a particular tool flow and they tend to scatter the information across several of these mini databases. And so teams end up relying on spreadsheets or email chains or just tribal knowledge to locate results. You know, when I ran this workflow, this is where you go find the results for this one. So if you don’t know the right person or you don’t have the right information, you could easily not know what’s going on, right? And so there are always cases where people are rerunning work workflows because they don’t know which version of a particular design was verified, whether they received the right data or not for the version that they’re using and so on, right? Now imagine this, but imagine the complexity just keeps increasing because we’re talking about not just small individual design blocks. We’re talking about SOCs, subsystems, SOCs, multi-chip packages that go into 3D IC, right? So now this becomes a real problem where the lack of clearly visible and available results in one place tends to make the system far more complicated. So this is where we call traceability is a big important part of what you’re doing in 3D IC space.

Tova (07:13.678): And I think probably a lot of people are going to recognize that issue, you know, different teams using different tools, information living in different places. And that might be difficult enough in a traditional design environment, but with 3D IC, the complexity goes up dramatically. And what is it exactly about 3D IC that makes data management so much harder?

Vishal Moondhra (Perforce Software) (07:43.142): Well, so if you think of 3D IC the landscape includes a package that has multiple dies, it has interposers, it has interconnects, it has packaging, it has all this other stuff in addition to just an individual SOC, right? And to begin with, an SOC is already complex enough, right? It’s got lots of internal blocks, it has a lot of details about it that make it tremendously complex to begin with. Now you multiply that by multiple SOCs, multiple different kinds of chips inside the same package, which are all connected with complex connections, right? And all of these end up being tracked separately. So 3D IC tends to make this whole problem a lot worse in terms of data management. Also one of the things that you have to realize is that if a small change that happens in one part of your 3D IC workflow, like an interposer changed or some interconnect changed, whatever, that can cascade across the entire design into multiple SoCs and goes deep into all of those, right? So these changes have to be tracked in one place. You can’t have siloed information where you’re tracking only certain things because you don’t know what’s being impacted. So in addition to the data volume itself being much larger because of the number of individual chips and chiplets inside a 3D IC package, you also have the fact that the effects of changes are cascading across a lot more bigger parts of the package. Then what we have not yet touched upon is the fact that AI is also driving a lot of the workflows and the number of times or the number of workflows themselves are multiplying because it’s much more easier to run these AI workflows given how much more simple it is to run those workflows themselves, right? So we are talking not just about the fact that there is a lot more data in a 3D IC package, we’re also talking about the new workflows, AI driven workflows, are delivering even more data to the end user. So this is a huge problem and it’s only getting bigger.

Tova (10:03.586): Yeah. So basically everything is much more connected and we have those ripple effects that can happen across the whole design. So how should designers think about managing interdependent changes across different design files and domains? And there’s something that Perforce defines as an atomic change. So can you explain that to us also?

Vishal Moondhra (Perforce Software) (10:29.509): Sure. So for example, let’s say a change happens in one die inside a 3D IC package or maybe an interposer or whatever, right? That would ripple across all the dependent components in the system. Now, if you don’t capture all of these changes together as a single unit of change, you could very easily run into a situation where only part of that change got captured. Maybe you know, only one die was captured, the change in one die was captured and not another. And so that can lead to severe inconsistencies and it becomes extremely difficult to debug. So you need systems that are atomic in the sense that either they capture everything or they reject everything, right? So you don’t have a partially committed, you know, situation or a partially captured situation where you don’t know what actually got captured and whatnot. So that atomic nature of capturing everything or nothing is a very critical part of having a solid foundation on the data management side, right? There has to be obviously tools that help you analyze what the actual impact is, right? What are the things that are going to get impacted? And when you do make that change, you want to make sure that all of that impact is captured in a single change.

Tova (11:53.891): Right. So it’s that all or nothing concept, that’s it’s a bit like making sure that all the pieces of a puzzle move together. Right? Because if only some of them move, that picture no longer fits. Yeah.

Vishal Moondhra (Perforce Software) (12:05.092): Yes.

Vishal Moondhra (Perforce Software) (12:08.866): Right, yeah. It’s all about consistency and making sure that everything is consistent, always.

Tova (12:13.974): Yeah. All right, so let’s step back from the specifics of tools or implementation, but at a higher level, what should engineering teams do to manage data well at this kind of scale?

Vishal Moondhra (Perforce Software) (12:29.860): So at this scale, it’s actually very critical to have a few fundamental building blocks of what you want to do, right? One would be to clearly separate the design data itself from the metadata. So the metadata is what describes what’s going on with the design, and the design data is the actual data that contains the design, right? So you need to separate the two and make sure that you have scalable systems that can scale both the data and the metadata independently because each layer can grow independent of the other, right? So you might have something that can handle gigabytes and terabytes of data itself. And then you may have a metadata layer that can also have very deeply connected graphs and very dynamic change management, right? And those are different scales. One is a lot of data and the other is a lot of dynamism. So you need to be able to scale these two layers independently. So your system should allow that. And thirdly, you want to use a platform that gives each person, role or workflow the information that’s relevant to that workflow and kind of does not overwhelm the workflow with unnecessary information, right? So that helps you manage the volume of data because you’re only picking and choosing and viewing the data that is interesting to you. Like for example, if you’re running a particular workflow, you may not care about the results of some other irrelevant workflow that’s also part of the data. So you want to only focus on what is needed for a given workflow or a given role. And so that allows you to partition this metadata and data into views that are relevant to the role. And then the final thing is to make sure that there is a single system that can manage all aspects, right? Whether you’re talking about individual blocks or sub blocks or you know SOCs, multi-chip, die, interposers, packaging, all of those, all of the data and metadata needed to work in all of those layers. If they are part of the same system, then it’s much easier to make sure that you have a single source for everything that you need.

Tova (14:46.242): Yeah, yeah. And that’s a critical thing, right? Working from a shared source of truth rather than parallel systems, which we’ve already seen how that can be, you know, that can go really wrong. That brings us to lifecycle management. So many listeners are probably familiar with PLM. But here we’re also talking about IPLM, which serves a different purpose.

Vishal Moondhra (Perforce Software) (14:56.888): Yes.

Vishal Moondhra (Perforce Software) (15:12.950): So can you define that for us? What is IPLM and how is it different from a PLM system?

Vishal Moondhra (Perforce Software) (15:19.674): Sure. You know, IPLM and PLM share three letters in common, right? They both have the terms PLM in them, but they’re fundamentally very different things. They’re actually not the same product at all. IP lifecycle management is what we call IPLM is different from PLM, which is product lifecycle management. So the PLM actually manages product level you know changes, you know, things like ideation, supply chain, you know, manufacturing chains, demand, you know, and the stuff that you want to build at the product level, where you’re looking at markets, you’re looking at how you’re going to actually manufacture a product and what’s the supply chain needed for that. So that’s a big emphasis for PLM. And so they have these slow moving but very consequential changes that apply at the product level. IPLM on the other hand is designed for the fast-paced design daily change management process, right? So it’s designed to capture what’s going on at the design level. You know, you fixed a bug, you created a new version of a particular, you know, leaf level node that can then ripple across your entire design, et cetera. Right. So that’s a fast-paced, everyday, you know, what design activity tends to produce is managed by IPLM. PLM changes are governed, right, very carefully. You can’t randomly just change a product because that could have impacts on everything that you’ve managed so far. You know, all your supply chain could be impacted, your manufacturing, your field deployments could be impacted. So every change at the PLM level is pretty heavyweight. It needs reviews. You have to make very conscious changes and you have to see the impact analysis of each change. Whereas IPLM tracks the rapid evolution of the design, right? Here’s what’s going on today. You know, this is the changes that this person, this engineer or this person has made you know on a daily basis. So together IPLM and PLM, IPLM enhances what a PLM can do by abstracting out all of this daily change noise and providing to the PLM a way to view the design activity at the level and pace that the PLM needs. So it’s like an abstraction layer built around the design activity.

Tova (17:42.115): Right. Okay. So behind all of this, you know, all of these processes and technology are real people trying to get their work done. And when the data environment is messy, that can have a very real impact on engineers, besides for the business impact that we already discussed. It has impacts on humans, the people working within that environment. So let’s talk about that human side of this. Who are the actual people dealing with this every day? And how does poor data management affect them?

Vishal Moondhra (Perforce Software) (18:21.155): So a lot of engineers spend time hunting for data instead of actually doing engineering work. So making sure that the right data is available to them, asking, you know, via various means, you know, whether it is email, Slack, you know, messaging, whatever it is, you know, walking across to an aisle. So just finding data becomes a challenge, especially when there’s a lot of it, right? And generally also if you look at the work that people have to do to keep to figure out whether things are on track, what’s falling behind, what’s not working correctly, each manager, project lead, et cetera. So if you go to that level, they end up having to ask or get the status from multiple different sources, right? You have to ask people, you have to look at a dozen different tools to find out what’s going on. And assembling all of that information can be difficult, messy, and very time consuming and mostly burdensome, right? The other kind of people we think about is there are some specialists, right? There may be somebody who’s just measuring the stress on the package or somebody whose job it is to look at the thermal hotspots and figure out how to alleviate those, right? Now they need to work in a team that makes sense for them. They need to have their dependencies worked out for them to get the right information. But often they end up working in silos because they don’t know or are unaware of what they’re doing might impact others, right? So that silo work methodology leads itself into these kinds of isolation because you don’t have a single system connecting all of them, right? So that’s where this underlying IPLM system or systems of that nature tend to make everything a little bit easier because you always know where to go and look for data. You’re not hunting around for it. And you also know the impact of somebody’s work, right? How that matters to you. So effectively what we’re seeing is there’s already an information overload because there’s too much data. It’s all over the place. People are hunting for it, right? And you’re buried in kinds of data you have to dig through and find your relevant files or relevant information from all this mass of data. And overall, you know, AI workflows are actually going to make it much worse in terms of the amount of data created. So the goal for all these teams is to present to each person only what they need when they need it, rather than have them swim through vast amounts of data and figure it out themselves.

Tova (21:06.904): Yeah.

Tova (21:15.181): And all of that time that they spend looking around for information, that’s time that they’re not spending on engineering, which is really inefficient. Yeah.

Vishal Moondhra (Perforce Software) (21:15.639): Yes. Yeah. Yeah. It’s both inefficient for them to be doing that as well as, you know, it tends to be frustrating because it’s quite often that you may not actually locate the right data, so you may repeat a workflow or you may have to cobble together something that you desperately need, right? So it’s not a healthy way. What you want is accurate and clear data so you can make progress.

Tova (21:39.865): Mm-hmm. So this can also become very challenging when someone new joins the team, right? If you have knowledge scattered across tools, emails, spreadsheets, and people’s heads, how do you do onboarding? So how does better data management help with that?

Vishal Moondhra (Perforce Software) (22:02.628): Yeah, I think you know, as you just mentioned, it’s clear that bringing somebody else on board, whether it’s a new, you know, maybe it’s a young kid, new college grad, or maybe it’s a person from a different team that’s joining your team and so on, right? So it doesn’t matter the history or the experience level of the person, they still need to spend a lot of time onboarding themselves and the team has to spend time onboarding that person onto the team. And if you have scattered sets of information, that’s a lot to absorb. It’s very inefficient to bring that person. It you spend maybe months trying to get that person to do useful work. And they have to also know and make those tribal connections, right? You know, you always go to person X when you need some answer about a power situation, but that may not be obvious to a new person, right? And they end up looking in the wrong place or just being left out because this is not documented anywhere. So it’s much easier if there is one system that you can go to and always ask the question and you always get the right answers, or at least, you know, most of the time you get the right answers. So that helps alleviate the amount of mental overload that it takes to onboard or bring on new team members.

Tova (23:21.794): Alright, so to close things out, let’s talk about how this is being addressed in practice through the collaboration between Perforce and Siemens. Right, Siemens tools generate a lot of valuable data across the design and verification flow. And Perforce brings IPLM as a way to help connect and manage that information more consistently. So tell us about how did this partnership come about and what does it mean for the future of 3D IC design workflows?

Vishal Moondhra (Perforce Software) (23:56.099): Sure. So as you mentioned, you know, Siemens has tools, you know, industry standard tools, Questa, Calibre, Solido, et cetera. And all of these tools, they do their work. As customers use them, they tend to create these databases of information, right? And these are siloed, rich metadata, you know, gigabytes of information, you know, but all of them, all these tools end up building their own little silo of information. And there has always been the need to break through those silos and put together a platform. But it’s difficult for a company like Siemens that is not in the data management business to come up with a unified platform that makes sense across their entire customer base, right? So Perforce proposed this IPLM as the unifying platform, what, I would say about three years ago. And it took a couple of years of working together through some technical details and understanding the needs of each of these tools and their desire for a formal platform for it to become a true partnership. And the partnership itself was formalized more than a year ago. So it’s a formal relationship between the two companies. And we have already started doing a lot of the integration work which was somewhat already underway before the formal partnership was signed. And so we are working with a bunch of Siemens teams. Most closely one is the Solido team, which is where you can directly today already connect all the Solido output, you know, whatever the IP verifications tools that they have directly into IPLM. We are working with the verifier team, the Calibre team, the Questa team. So we are slowly building this platform out where more and more tools can automatically integrate into the IPLM platform. But you know, in the meantime, while those tools are not yet fully integrated, we still have a mechanism by which you can do that with customers through API calls. And so either you do it directly or indirectly, but both are available today.

Tova (26:16.046): Right. That’s quite a game changer.

Vishal Moondhra (Perforce Software) (26:18.678): Yeah, it should be, yeah.

Tova (26:22.124): All right. Well, Vishal, thank you so much for joining us on the podcast. And there’s really plenty to take away from this conversation, but if I have to choose one main message, it’s that data management is no longer just a background process in IC design. It’s central to how teams collaborate, how they manage complexity and how they avoid costly mistakes. And ultimately, better data management means that engineers can spend less time hunting around for information and more time solving the hard problems that they were hired to solve, which is a much better use of everyone’s brain power. Thank you so much for joining us on this episode. We hope this gave you a clearer picture of why data management matters so much in 3D IC design and why putting the right systems in place now will only become more important as the industry continues to scale. Until next time, thanks for listening and stay curious.

Vishal Moondhra (Perforce Software) (27:23.404): Thank you.