OneSpin: A must see at DAC

There are three reasons you should visit OneSpin at DAC in San Francisco. First, they’re a German company, albeit with a group in California, so it’s great to chat with the German contingent while they’re in town; second, it’s been 10 years since they were spun out of Infineon, so they have that much experience selling verification tools into some of the largest semis in the world; and third, Dave Kelf heads up marketing for the company and any conversation with Dave’s going to leave you better informed and happy to be working in the industry. He’s the ultimate optimist.

I spoke by phone recently with Dave. It was morning in Silicon Valley and late afternoon in the U.K. as he described a new tool recently released by OneSpin that’s useful for evaluating verification coverage.

Dave said, “OneSpin’s been working on this for a while with customers. It was actually a customer who said to us: Look, you’ve got this great coverage engine. Why don’t you release it as a separate tool, because it could be very beneficial.

“So we looked at our coverage engine, added some features, made it useful to a number of different companies, and released it as Quantify. The response has been great. It’s really started to transform the environment for our customers, a group of very high-end companies.”

It’s not the first time an EDA vendor has bragged on a new release, so I asked about the usual question about the competition.

Kelf said, “That’s quite interesting. Today there are two major types of coverage. The first revolves around the idea of simulation or control coverage, which most people do – Cadence, Synopsys, all connected with their simulators.

“The coverage they check makes sure all the code in their RTL design is touched or tested by the simulation, if they roll the whole simulation. In theory, every line of code and every branch of instructions will be activated by the simulator. This strategy doesn’t ask, however, ‘If there’s a problem, will it be detected?’

“The other major class of coverage is to check the verification environment and understand that, if there is a problem, it will be detected by the checkers. This is called Observation Coverage.”

Does this technique guarantee the design is correct?

Dave said, “No, no guarantee. Although if there is a problem, it will come out using this technique. It’s not unreasonable to think, if you’ve written enough tests to activate the design, that problems somewhere in the design will be discovered. But they won’t be, unless you also have enough checks looking at the right things.”

This is always so confusing, the basics of verification. I asked about others who’ve looked at these problems, and got a short history lesson in response.

“There was a company which had a product named called Certitude, which was bought by Novas, which was bought by SpringSoft, which was bought by Synopsys,” Kelf said, chuckling.

“Certitude was a tool that used a similar approach to OneSpin’s Quantify, that actually went in and changed lines of code. The theory was that if there was a change in the code, the checkers would catch it. There were two issues with the strategy, however.

“First, it used mutation analysis, literally putting changes into the code and looking for the effects. But those mutations might actually ‘disguise’ themselves as correct bits of code. The other problem was that it required a huge amount of simulation. For a big design, you had to have a simulation for every one of the changes, but it took a lot time to run all of those simulation cycles.

“Despite these problems, however, the Infineon guys who are using the OneSpin Quantify tool today, are comparing the results favorably with the results of the Certitude tool they also use primarily for simulation coverage.

“The difference with OneSpin’s engine, however, is that we’re using formal verification in the detection process to ensure the observations are correct, increasing the precise nature of the technique. Quantify changes a single line of code, and that small change is detected because of the nature of the Formal engine.

“Our Formal verification also eliminates the lengthy simulations associated with Certitude. In addition, Quantify ties in a lot of the control-coverage techniques, which helps bring simulation and Formal together in a single verification flow.”

Jasper’s the leader in Formal today, I said, so are they pursuing these ideas? [My phone call with Dave took place prior to the news that Cadence was acquiring Jasper.]

Kelf said, “Jasper does provide coverage along the control lines, but as [their tool] has no notion of observation coverage, it’s far less accurate than ours. They haven’t apparently detected our idea, so we are still ahead in this technology. Combining Synopsys’ Certitude with Jasper’s Formal engine would get them closer, but still with the mutation issues noted, and you would end up with a somewhat disconnected flow.

“The fact is, what we have here at OneSpin is something no one else yet has. Jasper may be perceived as a leader, but we have the important technology. This is a very strong product, one that’s done well so far in Europe, and now we are working to get traction in the U.S.”

And how do you get the face time you need with customers to increase that traction?

Kelf was quick to respond and said, laughing, “Interviews like this, and shows like DAC. They’re both important!”

******************
At DAC 2014 …

OneSpin will demonstrate Quantify in Booth #1219, June 2nd to 4th, from 9 a.m. until 6 p.m. at Moscone Center in San Francisco.

******************

Tags: Cadence, Certitude, DAC 2014, Dave Kelf, Infineon, Jasper, Novas, OneSpin, Quantify, SpringSoft, Synopsys

This entry was posted on Wednesday, May 14th, 2014 at 11:29 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.