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: What’s the fallout of the splitting of the market into the really advanced customers and those lagging by several nodes?
Gray: Once people start doing FPGAs they have a different perception of what’s required for verification and what they’re willing to pay for. People can be a little lax with an FPGA because they don’t feel they have to do all that verification they did with an ASIC. We have some customers who actually want to do verification because they know it’s going to be hard to solve. But there are people who don’t think they need to be fancy. So how do you sell them verification IP?
Stellfox: That’s changing. The cost of failure at 32nm is high. There are more and more of those guys doing Xilinx, Altera and Actel FPGAs. Xilinx uses the term ex-ASIC refugees. We have a lot of these customers who are ASIC guys doing full ASIC flows—design, verification, timing closure—with all the same issues on an ASIC flow being applied to an FPGA. There are still the mom-and-pop shops, but when you’re talking about a very complex chip with embedded cores, that doesn’t converge. The same problems are still there. They may move to the FPGA because of the cost and the fact that they don’t have the volume to support an ASIC, but they’re willing to pay for the tools.
Narain: But the gap between what is needed for an FPGA flow and what is needed for an ASIC flow still exists. FPGAs are becoming more complex and ASICs are becoming more complex. At a high level you can say they’re both moving, but the automation requirements are going up for FPGAs. You still need to dumb down the tools because when you look at usage of the tools in these two worlds it’s quite different.
SLD: What do you mean by ‘dumbing down’ the tools?
Narain: You take a good look at the application and where a user is interacting with the application and what are they required to do. Then you automate it so you can reduce the amount of work they have to do. Pushing a button is dumbing down what they have to do. That requires a tremendous amount of engineering. This is true in clock domain crossings. The problem has not changed but the context in which the problem shows up today is nothing like what it was years ago. We have to continuously make it easier to use the tools. We’ve gone from a 10 million-gate design with 20 clock domains to a 50 million-gate design with 300 clock domains. People still want to get it done with the same amount of resources.
Stellfox: Maybe ‘dumbing down’ is the wrong expression. Adding more automation and putting more intuitive users interfaces is important. But that will still only go so far. There is still not enough verification expertise. Companies that have a strong verification culture can take someone with experience in verification and that person can do exponentially more with verification tools than trying to take bits of 10 different people who are doing verification part-time. It’s way more efficient.
Narain: I have heard that exact same statement that there are not enough verification experts for the past 10 years.
Bhatnagar: It’s going the other way. There used to be an army of people before doing design verification. Now the design part has shrunk because you’re buying IP. Verification has also shrunk because of economic conditions. Implementation has expanded.
Bergeron: We chose to make it go the other way.
Bhatnagar: Even when things improve it will still be this way.
Narain: You have to make high-level compromises. You do derivatives of the design. You make do with what you have.
Bhatnagar: If the design part is pretty much gone, why do you need so many verification resources?
Bergeron: Because that’s what’s left.
Bhatnagar: But what am I verifying?
Bergeron: You’re verifying the integration.
Bhatnagar: Exactly. But previously, when I had to do the design I had to verify the design and the integration. Now the design part is over.
Stellfox: But don’t you think the percentage of people doing the verification should be increased?
Bhatnagar: Yes, the ratio should always be two to one.
Stellfox: In the bulk of companies it has not been. It should be.
Bhatnagar: That’s where you use outsourcing. Verification is easier to outsource than anything else.
Gray: Is it? If you’re doing design or integration, you’d like verification to happen in the same location.
Bhatnagar: No, I want them separate.
Gray: I think that’s a recipe for disaster. The key to successful verification is getting the design and the verification engineers and the architects together in the same room. If you have them split apart the lack of communication is a killer. It’s a really bad choice.
Bhatnagar: As an engineer, I would like everyone in one place. But practically that can’t happen.
Gray: Then practically you should just take the whole thing to a lower cost area. You should be outsourced yourself if you take it to the logical conclusion.
Bhatnagar: I’ve done that, too. I’ve taken the entire design and implementation and verification to India.
Gray: Good. And how was that compared to when it was in the United States?
Bhatnagar: Crap, because the specialization wasn’t there.
Gray: That’s a different issue.
SLD: Let’s get back to verification. Can it be off-shored?
Bergeron: The lowest-cost venue is not always the most beneficial.
Bhatnagar: That’s true, but name one semiconductor company that doesn’t have offshore operations. And verification is an area that is self-contained.
Gray: It absolutely is not self-contained.
Narain: There are resource constraints.
Bergeron: When you move this to India and throw twice as many people on it, their inefficiency goes up immediately because there are twice as many people. And when you consider the skills are not there, it’s not as reliable, there’s long-distance management, and that it might have only taken two man-years if people were properly trained, it shouldn’t have happened.
Bhatnagar: I disagree there. The problem was the implementation team. The verification team was excellent.
Stellfox: In my opinion, Bangalore is at the leading edge of verification these days. The worst is probably Silicon Valley. That wasn’t the case 10 years ago. But if you separate things too much it can be a problem.
Gray: I’ve seen customers take that verification team very far away and it’s not efficient.
Bhatnagar: There is definitely a negative side to it. I’ve worked on chips where part was done in the U.S. and part was done in China and a third part was being done in India. It’s a problem.
Stellfox: You’re better off partitioning by functionality by putting a subsystem in one place.
Gray: Yes, by functionality versus discipline. So in Shanghai they’re doing the whole thing. That works great. Where you split it, that’s not good.
Bhatnagar: What we saw was little, stupid mistakes. If you can’t meet the timing then the pad needs to be placed here instead of there. Everything is impacted including the package even though it was done for timing closure.
SLD: What happens now that we have a larger software component in the design?
Bhatnagar: Verification doesn’t start at the RTL level. It starts with the C model. You have to develop the C model, then run your software on it, then generate the vectors that go into RTL.
Narain: Your RTL process has to be different from your C model?
Bhatnagar: They run in parallel. You have to match the C model.
Bergeron: It’s not a C model. It’s an abstract model. What gets written in C is an abstraction.
Bhatnagar: Yes, that’s correct. And the same model that gets written in software you want to run on an FPGA. That’s why you have emulation. It’s not a separate thing. Verification starts with C and runs all the way to gates. With an FPGA, you can have an early start with software development.
Stellfox: But more and more people are trying to differentiate their SoC by incorporating more of the software stack with the SoC. So how do you make sure your hardware differentiation is exposed to the application developers so they can take advantage of it? Software is a key differentiator. How you verify that with the hardware is fundamental. It’s not just being able to execute the software. Up until now, if the software didn’t crash it worked. We want to take some of the techniques we use in hardware and apply them to software. At a minimum, the embedded software is highly hardware dependent. That absolutely has to be robust. In the past, the handoff was the hardware.
Tags: Cadence, Mindspeed Technologies, Real Intent, Synopsys, Verification