The Next Problem In Verification
Last week’s blog on OVM vs. VMM was like a match on dry timber, which is probably a bad analogy to make in California these days. Weeding through the comments—both on the record and off, and there was plenty more off the record—it appears there’s plenty of work under way to bridge the two worlds, but there’s an inverse amount of information available to the people who use one or the other about those efforts.
Information kept in the hands of a few doesn’t help an industry progress. In fact, it sounds like something out of the movie, “Dr. Strangelove.” So as good responsible citizens of the design world, we’ll certainly help in that regard, both by providing a forum for discussion and identifying what’s changing.
That said, there’s a potentially even bigger issue brewing here. Communication seems to be a problem in the verification world, and that’s only going to become more of an issue because verification engineers have one of the hardest problems to solve in system-level design. There’s a reason that 70% of the time it takes to get a chip from concept to tapeout is spent in verification, and that’s only getting worse as we deal with more cores, more power domains, more voltages and mixed signal functions.
The problem is that verification engineers are considered after the fact, even though they represent the majority of NRE costs. For years, verification was a step taken after the design was already done. It now needs to be moved way up in the process to the point where verification is considered at the architectural level, along with whatever functions marketing wants in a device and what the power budget will be. In some cases, that may require IP up front to allow verification, and in others it may require tweaks to the design itself to make sure it can be verified quickly.
There will always be surprises in any design, and there will always be points in the design cycle of complex chips where brute force is necessary to meet deadlines. But communicating across the various stages of design with all groups that need to get involved has never been a particularly strong point of any team, and it is only made worse now that very few companies have their own fabs. That needs to change.
What do you think?
–Ed Sperling
Tags: ovm, verification, vmm
May 15th, 2009 at 1:08 pm
Ed,
I completely understand.
In automotive, we are facing the same challenge.
Exciting technologies available (Multicore, Flexray, Autosar, etc…) but not a clear recipe to leverage/optimize the resources.
Hence, in our design flow, captured by the V-cycle, verification is performed after system design, in the right-hand side of the cycle.
In reality, *prediction* coupled with *exploration* should be performed on the left-hand side of the V-cycle as the current design processes do not fullfill the requirements of shortening the time to market.
May 15th, 2009 at 4:00 pm
Hi Ed,
Communication is the #1 problem. Bad communication is like impedance mismatch; you can get the signal through, it’s just weak and distorted.
Assuming an engineer realizes that communication is key (two things we are not good at), the question becomes “How to communicate better?” There are many modes of communication (e-mail, presentations, etc.) but we should first agree on what it is we are communicating.
I suggesting taking a look at “The Design of Everyday Things”, by Donald A. Norman. It talks a lot about transferring a system model of how something is to work. This is what we are working to communicate!
A good example of this is a pilot flying a plane. Man those planes are pretty complex, but the pilots succeed. The trick is teaching models of how the various system work and interact. As long as the models and the implementation agree, the pilot can reason about how to use something without knowing how it works.
This is the exact same problem we face in verification. Verification engineers must strive to minimize the effort required to get somebody to understand how to use your verification code.
Only then can we talk about communicating effectively.
May 15th, 2009 at 11:25 pm
Hi Ed,
I agree that communication is key to reducing waste. Emails, documentation, wikis, presentations, meetings, hall way discussions are necessary but not sufficient. In my role as verification lead at my last job, I found that even status reports with test scores and coverage numbers are no guarantee of quick verification convergence.
Management needs to realize the importance of verification, and this applies not just for ASICs, but FPGAs as well. Teams needs to establish sound process and get appropriate tools that enable structured yet natural communication without loosing site of the overall goal.
We are creating such a tool (called IVerifySpec which we plan to show at DAC) that would address this problem head on.