Experts At The Table: Yield And Reliability Issues With Integrating IP

Semiconductor Engineering sat down to discuss the impact of integrating IP in complex SoCs with Juan Rey, senior director of engineering at Mentor Graphics; Kevin Yee, product marketing director for Cadence’s SoC Realization Group; and Mike Gianfagna, vice president of marketing at eSilicon. What follows are excerpts of that conversation.

SE: As more pieces are integrated into complex SoCs they don’t always work as planned or they don’t yield as planned. How do we solve that?

Rey: We focus on the interface between design and manufacturing, and there are a lot of things happening there. We are seeing more complexity, but that’s only part of the problem. It’s also moving to smaller nodes. And there also is quite a bit of complexity in established nodes caused by IP integration from multiple vendors. With that, there is also an interest in improved reliability from specific market segments, such as the automotive market. Several of these vendors are not continuing with an IDM model. They are integrating IP. In trying to do that, the issue of reliability and combining IP from multiple vendors brings new needs into the market. What we are seeing is a push toward automating test, which people have been developing by hand or doing in a very ad hoc manner. It requires bringing information from multiple domains that traditionally have been different, such as parasitic extraction mixed with standard physical DRC verification for the sample checking, plus how do you get connectivity from the netlist. And from all that you need to do more advanced checks. We also see quite a bit of interest in reliability. The TSMC 9000 initiative is a good example of where there is a need for getting new tests incorporated into the design flow. That is a trend that is gaining acceptance, because it improves reliability and productivity.

Gianfagna: At one level you’re describing the classic IP problem—how do you take IP from multiple sources and get it to all work together. There’s been a lot of discussion about that. But there are also the challenges of moving IP from one process node to another and surprises in yield. We polled engineers and designers at eSilicon—we’ve done more than 300 tapeouts—and one thing that’s a clear trend is that if you take a piece of working IP and you need to tweak it or change it, overwhelmingly that’s the reason you need a re-spin. You touched the IP. There is a surprisingly large correlation between touching the IP and the need to have a re-spin. That’s a somewhat daunting statistic. But on the other hand, you have to touch it. So what do you do? One of the things we’ve seen is interest in multi-project wafer runs inside a shuttle. You can fill out a form and get a slot on an MPW so more people will use those functions to validate the IP. If you have to touch it, you run silicon and verify it still works. The tricky part is that tells you if the IP is functional and manufacturable. It doesn’t tell you if it’s going to yield. It’s one slice and one process corner and one instance at a time, but it doesn’t tell you anything about yield learning or overall process performance. So how is it going to yield over time? A lot of times you don’t know if you’re close to a yield cliff, whether you’re too close on too many corners. If you re-use IP without touching it in a new design at the same process node, you generally don’t have that problem. As you run more and more designs, you get more information about how IP works and how it will yield and what the performance will be. The question is whether you can use that data to not only chronicle the past but also predict the future. Indeed there may be ways to do that, and that will help mitigate this problem.

Yee: We break IP down into hard IP and soft IP. Hard IP is often a PHY or analog, versus a controller, for example, which is soft. Some of the challenges don’t apply as much on the controller side because soft IP is synthesizable. You have flexibility there. In terms of a flow and a delivery to customers, we’re tried to put as much flexibility into IP as possible on the controller side. In terms of tweaks, that’s already built in. We do different configurations for customers, so for our DDR we have more than 1,500 configurations you can set up. But we don’t just tweak it. We run a regression to make sure it’s running. If you don’t just tweak it, then the chances of it functioning correctly and having bugs is severely minimized and you have a lot more confidence. On the hard IP side, it’s about the ecosystem. We’re seeing process changes, and you have to work with the foundries, the customers and the tools. They all work together today. When we work with GlobalFoundries or TSMC, we work very closely to understand their process changes. If you do tweak from one process to another, what changes will be there? If we don’t know what the foundry is doing, any migration from one to the next can cause everything to fall apart. We spend a lot of time working with foundries to understand what process changes are there. We try to do as many test chips as possible. With regard to IP manufacturability, this is very different today than it was 20 years ago. In the past, IP was created in a vacuum. Today, you have to think about the system and the SoC, the interfaces, how interoperable they’re going to be. At some point, you’re looking at the applications and the systems they’re going into. We build in scan chains for manufacturability. In the past, you wouldn’t even have considered that.

SE: Are we starting to impact the yield equation as we add in more third-party IP? Is it getting harder to say something will yield well?

Gianfagna: It’s definitely more difficult. If I’m an IDM and I own all the IP and the fab, you have a very clear understanding of where the process corners are and where the yield cliffs will be. And as you build IP, you have the unified methodology to ensure everything sits in unacceptable envelope around those corners. Once you start dealing with third-party IP, does everyone even have the same data? The foundry is behind a different firewall than everyone doing the design. It’s now who is the IP provider and how good is their access to the foundry and their data. When you’re working with foundry partners, that’s not a casual relationship. That’s a lifetime marriage. You really have to work closely with those people to understand what they’re doing and track what they’re doing. Do all the providers of IP in an SoC have that relationship? Have they done the requisite analysis to ensure the IP is centered on that process? This leads to what is politely referred to as IP qualification. What that really means is the end user is fixing what they bought so it works. There’s a lot of work that goes on there. We have to bring IP up to a level of quality that we can trust and which will yield the first time. It’s a challenging problem.

Rey: There are physical dependencies. Even if the IP provider takes care to have a good understanding, they are the first ones that typically are in touch with their manufacturing people so they understand the dependencies and what kind of variability they need to be able to cope with from a process point of view. And there’s a limit to what can be done. That may be different than when you get IP and analyze it in context. There are many manufacturability tests for what will be the process variability impact on the electrical characteristics of your system that are prone to failure because now you are checking the IP in the context of whether it can be manufactured. That may not have been the context in which was characterized before.

Yee: IP development is one part of it. Just because SoCs are more complex, that brings on a ton of challenges. But along with that, when everyone owned and developed their own IP, they really understood it. They understood the functionality. Today SoCs are so complex that a lot of engineers using IP have no idea what that IP does, including the protocol.

SE: That’s the black box problem, right?

Yee: Yes, it is a black box and that provides new challenges. In some ways, the IP market has evolved a lot. In other ways it hasn’t evolved at all. You really have to trust the IP and know there was sufficient investment in it—not just a guy in a garage creating his own IP. There is a lot of IP out there from developers who have no relationship with the foundries because they’re too small. Those are the chances you take. And now that the end customers don’t understand the IP, they don’t understand what’s good IP and what isn’t. It’s a black box to them. If they’re putting in 50 different IPs, they can’t be expected to understand it all. There’s a trust factor about where you’re getting your IP and whether it’s validated to the point where you know it’s going to work.