editor's blog
Subscribe Now

Working Forward

You may recall that Vennsa’s OnPoint tool takes the results of verification and helps identify errors and possible causes. The tool’s early focus was on identifying suspect issues and letting you work from there.

Last year around DAC time, we noted that they took things a step further to suggest possible fixes (but you had to confirm whether they truly were fixes) and to do a better job of triage, clumping together things that might have a common cause.

But this is all reflected the backwards tracing that is typical of debug: find an issue and work back to possible causes. This is as opposed to forward debug, which, in its worst manifestation, consists of guessing at places to make changes and following the changes forward to see if they fix things. Couched in those terms, the forward approach sounds more like an act of desperation.

This year they have improved their “causality engine” to the point where you can start with proposed fixes and see the chain of logic from each proposed fix to the now-corrected problem point that demonstrates that the fix works. You can work forwards, except that now the specific locations of fixes and the values that fix them are provided by OnPoint rather than by a wish and a prayer.

It’s important to note that the “fixes” proposed aren’t circuit fixes; they’re just logic values (and times, in the case of state machines and such) that will remove the offending behavior. You still need to come up with a circuit change to implement the fix and then simulate it to ensure that you haven’t created a problem for yourself anywhere else.

One of the benefits of this is that the verification folks can now save the design folks lots of debug time. Before, a block might get handed back to a designers saying, “There’s a problem; here’s the test that failed.” Now that information can be accompanied by, “And here are a series of solutions from which you can choose.” Makes for much friendlier interactions.

You can find out more in their release.

 

Leave a Reply

featured blogs
Oct 24, 2024
This blog describes how much memory WiFi IoT devices actually need, and how our SiWx917M Wi-Fi 6 SoCs respond to IoT developers' call for more memory....
Nov 1, 2024
Self-forming mesh networking capability is a fundamental requirement for the Firefly project, but Arduino drivers don't exist (sad face)...

featured chalk talk

Versatile S32G3 Processors for Automotive and Beyond
In this episode of Chalk Talk, Amelia Dalton and Brian Carlson from NXP investigate NXP’s S32G3 vehicle network processors that combine ASIL D safety, hardware security, high-performance real-time and application processing and network acceleration. They explore how these processors support many vehicle needs simultaneously, the specific benefits they bring to autonomous drive and ADAS applications, and how you can get started developing with these processors today.
Jul 24, 2024
87,171 views