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

For all the talk about VMM vs. OVM and how it doesn’t matter…well, apparently it does.

It’s not that one verification environment is so much better than the other. That’s like saying one religion is better than another. People kill each other over those kinds of statements. And the truth is, there are plenty of people who will argue for and against each side.

Strangely, when you really dig into this, you’ll more than likely never get a straight answer because most people don’t know both methodologies. They learn one and that’s complicated enough for most mere mortals.

But complexity is getting to the point even at the most mainstream process nodes where verification headaches are becoming overwhelming. More transistors, multiple cores, multiple power islands and various on, off, and sleep states makes the need for better verification methodologies, languages, and base classes almost essential for debugging these designs. And it doesn’t help when there are different people in an organization with expertise in different methodologies.

There has been talk about bridging the two environments, matching data types or wrapping code. But so far, there has been little progress in this arena and the time needed to verify increasingly complex designs grows accordingly. Where are those corner bugs hiding? You’d prefer not to find out after a product is already out in the market.

It’s time this issue came out in the open instead of being stuck in standards groups. In the past, who used what verification methodology didn’t really matter. But it matters now, and the verification problem is only going to get worse.

What do you think?

–Ed Sperling