Experts At The Table: Verification
By Ed Sperling
System-Level Design sat down to discuss verification with Synopsys fellow Janick Bergeron; Mike Stellfox, distinguished engineer at Cadence; JL Gray, vice president at Verilab; Himanshu Bhatnagar, executive director of VLSI design at Mindspeed Technologies, and Prakash Narain, president and CEO of Real Intent. What follows are excerpts of that conversation.
SLD: Verification is the lion’s share of design. It’s the biggest cost center. What needs to be solved?
Gray: A lot of the issue with verification, in addition to the tools, is that there is an element of planning and managing the complexity of the verification project. I’ve been on some projects recently where this is the issue. The rest is managing the details of a large SoC project and how you deal with all the pieces. Controlling that complexity is not something that everyone can deal with.
Bergeron: The challenge in verification is what it has always been, which is something that is exponentially more complex than the design activity. You have to realize this is something that requires planning from day one and it requires skills—a different set of skills. We have a wide variety of tools. There has never been a silver bullet and I don’t expect there will ever be. And you have to have the skill, knowledge and expertise to be able to take advantage of all the technologies that are out there. The single most effective thing one can do is learn to use the tools that are out there rather than asking EDA vendors to dumb it down. I’ve been saying that for 15 years. We need verification specialists just like we need timing closure experts in submicron design, and those skills are different. You cannot have a jack-of-all-trades anymore. You need dedicated people who are more software-oriented.
SLD: If this message has been circulating for 15 years there’s an even bigger issue, which is the readiness of engineers to solve these problems.
Stellfox: I’ve been preaching the same thing since I started focusing on verification. Any company will tell you they spend 60% to 70% of their time in verification and it’s getting worse. But when you ask them, ‘Where are all your verification engineers,’ they tell us, ‘We can’t afford to have verification engineers.’ If you’re spending 60% to 70% of your time on something you need people who specialize in that. The skills for verification are completely different than design skills. That’s the number one issue. We have a lot of technology out there, but there are not a lot of people who can apply it. There’s certainly more we can do to bring faster automation and execution platforms, but as Janick says, ‘You can’t dumb it down’ because it’s a complex problem. And now with everyone building platforms and complex SoCs, the problem now is integration verification and with verifying hardware and software together. I was talking to a customer the other day who said it should no longer be called EDA. It should be EIA, for electronic integration automation. With SoCs there is less design. It’s more about integration.
Narain: Verification is not a uni-dimensional problem. That’s why you need planning. Once you have a plan, then you need to implement it. To do that, you have to have those components that make up your plan properly tooled. Even where there are tools, they are breaking down. The design complexity has increased over the last 10 years and the problem has increased on a curve, not as a step function. It is getting worse and there are pieces missing. Having said that, there are people putting out designs and they have to make a business. From my perspective, there is more integration. The earlier you can do this and the least expensive technology you can use to find your problems the better off you are. But in 2000 we used to talk about a 10-year re-tooling cycle for EDA. We have tools that take 20 hours to run. We don’t run those tools because it takes too long and the performance isn’t there. Now we have designs with 300 clock domains. DFT design complexity has gone through the roof. It’s not just a functional verification problem. The tools are old and they are not keeping pace.
Bhatnagar: I agree with everyone, but when there is an economic downturn there are layoffs and there is no choice but to dumb down the tools. That’s innovation. It has to happen. Functional verification can be broken down into dynamic and static. The complexity is going through the roof and there’s no way to go through dynamic verification all the time. You have to go through static. That’s where progress has been made—in the assertions. But it’s another language and another way of implementing it. Plus, if I know where the holes are I’m going to fix it. That’s where the newer technologies will help—analyze the RTL, analyze the intent and plug the holes with assertions.
SLD: One of the goals among companies these days is re-use. How does that affect verification, particularly if what’s being re-used is not exactly the same way it was used before?
Narain: If you look at test re-use, test costs are going through the roof. We are looking at DFT techniques. The complexity of DFT verification is increasing. But they are re-using that technology effectively. It’s harder to do that in verification.
Bergeron: I hear about test re-use from customers and it’s always something I like to push back on and ask what is the motivation. On the design side it’s easy to see the perceived value of re-using a block. You don’t have to re-design it. The block has some tests and you’d like to re-use the test.
Narain: I was referring to manufacturing test.
Bergeron: But with manufacturing tests you have a clearer understanding of the intent and you can automate and scale. But with verification, if you have a test for an IP and you’d like to re-use it in the SoC, then what are you testing? What’s the purpose?
Bhatnagar: On the DFT front, the only thing you can re-use is memory BIST. Everything else has to change.
Stellfox: For design re-use, the key is verification. If you give someone a piece of design IP and it has no verification around it, the ability to re-use it is very limited. Typically the design IP is not kept 100% intact, so it has to change somehow. That means you need something that goes along with the design IP that captures the intent of how that IP was supposed to be executing, which basically is the verification. Verification is just a means to an end. I’ve had customers tell me they can’t invest in verification because they don’t make money on verification. They make money on the chip. The only reason you want re-usable VIP is that it’s a big investment to create it. You don’t want to have to re-create it. But the whole goal is re-usable IP. Verification is essential for that, and by definition VIP is essential to that.
Bhatnagar: The EDA vendors have done a good job there. There is VIP available for just about anything you can name. From Synopsys, three quarters of them are free, which is even better.
Bergeron: And you’ve just hit on one of the problems. For the exact same reason that you don’t make money with a test bench, there is very little perceived value with VIPs. They’re costly to create. It’s a huge software effort. People are willing to pay for design IP, because there’s perceived value and a model. For VIP, it’s hard to make a business at it.
Bhatnagar: That’s right. From a user perspective you can’t create a design without it. From a management perspective, I wouldn’t think about buying it. But you can limit the number of licenses.
Gray: But if you limit the number of licenses you’re actually raising questions about whether you have enough resources to buy it. So why not go write your own because then you have as many licenses as you need?
Bhatnagar: That’s correct, but you always have a limited budget and you have to do things within those boundaries.
Bergeron: But then you expect the VIP to be defect-free and come with a compliance-test suite.
Bhatnagar: But no one sells you just the VIP. It comes as part of the IP package. You buy the IP and you get the VIP.
Stellfox: We’ve seen huge growth in this business at Cadence. In the last couple years we’ve built a huge OVM-based portfolio of verification IP. It’s a standalone business. It’s also supporting our overall business. When you go to a project you have to balance the investment with VIP, tools, and so on. We actually see it as a profitable business and we’re investing a lot there. We also see companies, because of the need to do less design and more integration, investing there.
Bhatnagar: I completely agree with you. Out of the three parts—verification, integration and design—the design part is gone. Mostly it’s integration today. And in integration, what are you testing? Are you testing just the connections, or are you testing bandwidth calculations and performance? You absolutely need VIP.
SLD: Then there’s a fundamental problem about how to extract value from all this work, right?
Narain: Yes, but he is willing to buy IP. He expects VIP to come free with it.
Bhatnagar: Unless there is specific VIP that’s needed. That I will pay for.
Bergeron: With new titles in the early days of the industry, a customer typically would not buy VIP from the same person that developed the IP because if there was a bug it wouldn’t show up. They would buy VIP from another person.
Stellfox: It’s still that way. The more savvy verification customers prefer to have the VIP separate from the IP.
Bergeron: You first establish protocols.
Stellfox: Yes, you’re right. Like PCI Express generation 3. Then it’s high value.
Tags: Cadence, Mindspeed Technologies, Real Intent, Synopsys, Verification, Verilab