In the news

Managing Faults: OneSpin’s Dave Kelf talks ISO 26262

EDACafe logo

By Peggy Aycinena, EDACafé

In a recent conversation with OneSpin’s Dave Kelf, he laughed when I asked him to characterize the complexities of meeting functional safety standards when developing automotive electronics. “It’s a whole rat’s nest of certification,” he said, “and as an industry we’re not there yet.

“However, at OneSpin we have a good handle now on what you need to do to make these cars safe. We’ve been working for quite a while with Bosch, Infineon, and other companies that really have a good idea of what needs to happen with the chips in cars to make them safe.

“In fact, a large part of the regulations come from these guys because they’re the experts, along with some level of government oversight, in trying to make sense of it all.”

Read more

EDA Tackles Functional Safety

Electronic Engineering Journal logo

By Bryon Moyer, EE Journal

Meanwhile, OneSpin has also newly addressed this space. Their approach to dealing with systematic errors harkens back to messaging they were using many years ago: gap-free verification. This gets to the notion that, given a set of design requirements, the design should behave in a way that meets all the requirements and nothing more than those requirements. Every element of the design should be necessary and sufficient. Any behavior that lies outside those specified in the requirements become an issue. So, clearly, this is something that OneSpin has cut its teeth on.

For random errors, however, they have an approach different from – and potentially complementary to – Austemper’s. OneSpin’s Dave Kelf noted that, after simulation-based fault analysis, there typically remain on the order of a couple hundred uncertain faults that need to be checked manually. And real-world speed is such that one can address roughly one such fault per day. But, of course, OneSpin does everything using formal analysis rather than simulation, so this issue goes away.

OneSpin has three applications for handling random errors. FPA starts by pruning non-propagatable faults from future analysis. After all, if a fault occurs and it never gets to or affects an output, did it really happen? Truly navel-gazing stuff, but, from a practical standpoint, time need not be spent on such faults. You could say that such faults are self-handling.

FLA then looks at fault-handling circuits to prove that they work. OneSpin had to add some functionality to their tools to make this second tool work – something that might sound trivial: force and release. Those are, in fact, trivial to do in a simulator, because they’re event-based commands that blend well with a simulation mindset. But they’re not so obvious with formal verification – and yet they were necessary for proving that an injected fault can be handled.

Read more


Is Design Innovation Slowing?

Semiconductor Engineering logo

By Brian Bailey, Semiconductor Engineering

The notion of horizontals has changed over time. “There are many layers of software and then services on top of that,” added Dave Kelf, OneSpin Solutions. “Lower levels of software are becoming more like hardware. As it becomes a bigger problem, the lower-level blocks become commoditized and a service to the higher-level blocks. It is the highest-level that many associate with innovation.”

Read more

IP Challenges Ahead

Semiconductor Engineering logo

By Brian Bailey, Semiconductor Engineering

Another problem for some IP companies is scale. “The market is such that IP vendors tend to be small companies and the customers tend to be big companies with lots of purchasing power,” remarks Dave Kelf, vice president of marketing for OneSpin Solutions. “If the big company has all of the buying power and there are multiple companies trying to produce the same IP, then it becomes a tough market and the big companies know that they can squeeze on royalties.”

Read more

EDA Tackles Functional Safety: New Tools for Safer Designs

by Bryon Moyer, EE Journal

For years, when we have thought “functional safety” or “safety-critical design,” we’ve pictured airplanes, spaceships, and weapons. All of these systems rely on tons of electronics, and they have to work properly or else bad things happen – either lots of time and money lost or lives lost.

And so, for years, the “mil/aero” world has been its own special thing. Some companies specialize in that business because margins can be good. Others stay away because design cycles are long and unpredictable, and there can be tons of paperwork – and who needs that, right?

[...]

Meanwhile, OneSpin has also newly addressed this space. Their approach to dealing with systematic errors harkens back to messaging they were using many years ago: gap-free verification. This gets to the notion that, given a set of design requirements, the design should behave in a way that meets all the requirements and nothing more than those requirements. Every element of the design should be necessary and sufficient. Any behavior that lies outside those specified in the requirements become an issue. So, clearly, this is something that OneSpin has cut its teeth on.

For random errors, however, they have an approach different from – and potentially complementary to – Austemper’s. OneSpin’s Dave Kelf noted that, after simulation-based fault analysis, there typically remain on the order of a couple hundred uncertain faults that need to be checked manually. And real-world speed is such that one can address roughly one such fault per day. But, of course, OneSpin does everything using formal analysis rather than simulation, so this issue goes away.

OneSpin has three applications for handling random errors. FPA starts by pruning non-propagatable faults from future analysis. After all, if a fault occurs and it never gets to or affects an output, did it really happen? Truly navel-gazing stuff, but, from a practical standpoint, time need not be spent on such faults. You could say that such faults are self-handling.

FLA then looks at fault-handling circuits to prove that they work. OneSpin had to add some functionality to their tools to make this second tool work – something that might sound trivial: force and release. Those are, in fact, trivial to do in a simulator, because they’re event-based commands that blend well with a simulation mindset. But they’re not so obvious with formal verification – and yet they were necessary for proving that an injected fault can be handled.

Finally, they have FDA, which quantifies fault coverage. It still requires some time to run – weeks for a large-scale design – but there’s no need to generate scenarios or vectors, as is needed with simulation. And there’s none of the uncertainty and dispositioning that are required for simulated faults, saving literally hundreds of engineer-days.

There’s even some talk with Austemper to see whether a formal engine might be more effective than simulation for Austemper’s Kaleidoscope tool. This is the “complementary” bit that I referred to. It’s not certain whether this will happen, but it shows how different solutions may overlap in constructive ways.

Read more

And The Winners Are… 10 Formal Solutions To Einstein’s Riddle

Semiconductor Engineering logo

By Sergio Marchese, Semiconductor Engineering

A few months back, OneSpin asked engineers to solve the classic Einstein’s Riddle using a formal tool. The challenge became hugely popular, and we received many outstanding solutions. To check out the riddle itself and the top 10 solutions created by leading engineers, click here.

Read more

How Much Verification Is Necessary?

Semiconductor Engineering logo

By Ann Steffora Mutschler, Semiconductor Engineering

“A lot of verification is actually process oriented,” said Ashish Darbari, director of product management at OneSpin Solutions. “It’s about putting the right technology, the right resources, the right stage of the project, and obviously getting the right people involved. The challenges of technology in terms of design are huge. If you thought initially it was Intel’s high performance computing, then low-power came along, and power became the over-arching requirement for design. Now you have safety and security, while power and performance are still there. So the requirements are only increasing.”

Read more

Press Contact

portrait of Nanette Collins

Nanette Collins
» nanette@nvc.com
» +1 617 437 1822