What Goes Wrong With IP

Semiconductor Engineering sat down to talk about the future of IP with Rob Aitken, R&D fellow at ARM; Mike Gianfagna, vice president of marketing at eSilicon; Judd Heape, vice president of product applications at Apical; and Bernard Murphy, an independent industry consultant. What follows are excerpts of that discussion, which was held in front of a live audience at the recent Silicon Valley IP Users Conference.

SE: In the past, if you bought IP you had no idea if it would work by itself. While the quality of IP blocks has improved, the complexity around that IP has increased to the point where, once again, we’re not certain it will work. What can go wrong and how do we fix it?

Gianfagna: The IP has gotten a lot better. The documentation is better. The quality assurance has improved. It’s somewhat ironic, but consolidation has improved that. But the thing that still bites you is the interaction between the different IP blocks. There are a lot of surprises. It’s the combinatorial effect of different IP blocks and multiple sources working together, and there isn’t a lot any one vendor can do about that. It’s really up to the design team to figure that out.

Aitken: There is a lot that is right, but there also is a lot that can go wrong—and that fits into a couple of different categories. One is incorrect expectations. If people think it’s going to do something that it doesn’t, that leads to trouble. A second problem is that a given chip architect can handle only so many things in his brain at one time. When you exceed that, you start running into issues of things falling through the cracks. Someone forgot to buy something or they didn’t realize that it only worked on some other process and not this one. But the general problem of making sure the specifications are right, that the validation strategy is in place, and that you understand how the blocks were meant to work with each other, is probably the biggest problem from a chip architect standpoint.

Murphy: It’s a lot better than in the past, but there are still big challenges. One is functionality. You have a piece of IP that maps to certain expectations that the IP developer had, and they’ve tested that against various customers. But the possible number of places that IP can be used is infinite. When you put that piece of IP into some slot that’s going to be exercised in a certain way, you don’t really know if you’re going outside the bounds of that use model. You document very carefully what you think the use model should be and you test it very carefully, but that doesn’t mean the user is going to use it that way. You’re not talking about mainstream usage here. You’re talking about the fringes. That’s a problem. And if you look at hard IP, there is a challenge with on-chip variation timing models. Now you have these IP descriptions with gigantic timing tables and they’re verified by scripts. You have your scripts. I have my scripts. But do these things really align? If I put my in-house SerDes in there and you have your own memories, do I have the same expectations of how I’m modeling OCD that you have? There’s no leveling across the industry for that.

Heape: Normally for us as an IP provider things go right. But when they do go wrong, it’s because specs are not read, or are misinterpreted, by our licensees. We provide imaging cores, which are often subsystems. But sometimes our licensees won’t properly simulate or model bandwidth across frame buffers or things like that. If they’re implementing our IP, they won’t have allocated the proper amount of bandwidth and suddenly they have to turn off a feature. Because it’s imaging and because we’re dealing with large data video, sometimes it’s impractical for them to simulate hundreds of frames of video. They make a mistake of thinking they can implement something with a certain amount of bandwidth and in actuality it’s five times that number.

SE: Are the problems worse as we move to 16/14/10nm, or are they the same at ever node?

Aitken: You’re exchanging one set of problems for a different set. Ten or 15 years ago, there was a general belief that IP was the same as design. If you designed a block and it worked, then you could say this is silicon-proven and therefore it’s an IP block and you could sell it. Essentially it was proven in one particular application at one particular moment in time. If the spec for the IP block is greater than the application of it on that particular chip, not only is there a good chance there’s a bug, there’s almost a guarantee that there are bugs in the parts of the spec that were irrelevant for that particular implementation. As we’ve gone down to 16/14/10nm, you get fewer people playing in this space, so that kind of problem diminishes. Now you get a different problem. What does it mean to sign off at one of these nodes? That’s a complicated problem in itself. It’s less of a problem for synthesized IP because that’s an RTL block, so what happens when you implement it is pretty much what the designer thought. For hardened IP, it’s definitely an issue. It’s an issue not just from the digital standpoint, but for analog because there’s noise wandering above the chip and there are things happening on the power network that don’t conform to what people thought would happen there. There may be very low-frequency issues.

Murphy: The timing gets worse as you go to lower nodes. Functionality gets worse as the function gets bigger or less road-tested. That’s a challenge we still don’t have a good handle on solving. How do you communicate what the legitimate use is for a piece of IP in a portable standard way?

SE: Doesn’t part of that depend on what it’s physically next to?

Murphy: One of the challenges is to anticipate what you didn’t test. Maybe you can use synthesized assertions. In principle, assertions are a great way to test the effect of a piece of IP’s neighbors. The problem with manually generated assertions is they’re hard to write. So you think about how that piece of IP might be misused, you write those assertions, and then you run out of gas because it was so hard to write those assertions. And that’s still not going to test for unknown unknowns. So how do you generate assertions to determine whether this piece of IP will be abused in some way? Synthesized assertions may be one way. There also is some work happening on models that represent declarative VIPs rather than functional VIPs. They test what they expect something will be used as. So they’re looking at coverage metrics and assertions, but because they’re declarative they’re not saying how you should do the testing. As a result, they can be used in situ in the main design and test for the things they expect the IP should do or be exercised to do. But it’s also not limited to what you’re next to. You’re also under the control of a power manager or a security manager or whatever else might be going on.

Aitken: You need to have the infrastructure on the design to be able to do that. There are software-based things you can do to patrol around, as well as hardware-based things. But if you haven’t thought of that as a problem up front, it’s going to be very hard later.

Gianfagna: We’re both an IP supplier as well as an ASIC supplier. We build IP and we build chips using IP from other suppliers. Every chip has a half-dozen to a dozen different suppliers. That’s a problem. The elephant in the room is most IP has this deductive proof around it. You can synthesize it or run a test chip in this application space, and then by deductive proof you conclude it can be used in all these other application spaces. There’s no way around that because you can’t conclusively test IP in all conditions. It would be late to market and it would cost a fortune. So what do you do? One thing we’ve seen is there’s an opportunity to employ big data applications and analysis here to your advantage. If you can maintain a database of all the chips you’ve taped out and all the IP you’ve used, and then when you have a new configuration of IP map that onto the solution space you’ve used before, then you can do some interpolation and do some analysis that shows where the hot spots will be and how to address those.