At DAC this year, I expected to see the usual run of the mill updates to existing tools, and a few interesting extensions. I had expected to see lots going on in the rapid-prototyping arena and while I was not wrong about the number of announcements in that area, I was wrong about the quality or significance of them. Maybe next year. However, I think there are some surprises every year, and Vennsa provided me with one of them.
I have seen the charts that show how important verification is and an equal number of charts that show that a significant amount of time (like around 50%) of a design and verification engineer’s time is spent on debug. We see lots of tools that enable you to generate tests quicker, but what about debug the tests when they fail? That is the area that Vennsa has chosen to tackle.
Vennsa OnPoint™ is an automated debugging tool that localizes the source of errors without user guidance. OnPoint picks-up where conventional verification tools leave off. It helps with high level failure triage by determining whether regression failures are caused by the same or distinct error sources. Furthermore, it helps with low level root cause analysis by automatically pointing to the lines of code where the problem can be fixed. It improves productivity, saves months of effort and guarantees faster design closure.
Triage Triage is the process of debugging failure regressions at a high level. The main aim is to quickly and accurately identify the general source of the error and determine the proper engineers to fix the failures.
OnPoint’s triage engine provides an "X-ray" of the path the bug takes from its origin to the checkers. Using these paths, OnPoint can distinguish between different bugs and categorize them accordingly. OnPoint triage can accurately answer questions such as • Which failures are caused by the same or distinct error sources? • Who is the best candidate to perform root cause analysis? • How to bin the failures for most effective root cause analysis?
Root Cause Analysis OnPoint automatically analyzes verification failures and identifies the source of errors in the design. Its inputs are the design, a simulation value dump file (FSDB, VCD, etc) or a counter example that expose a simulation mismatch or a failing assertion. From this, OnPoint creates a suspect and provides this information related to that suspect: • Locations in the source code where the bug could be found • Waveforms showing the fix values • The times when each bug is active • Cause-effect and correlation information
David Patterson, known for his pioneering research that led to RAID, clusters and more, is part of a team at UC Berkeley that recently made its RISC-V processor architecture an open source hardware offering. We talk with Patterson and one of his colleagues behind the effort about the opportunities they see, what new kinds of designs they hope to enable and what it means for today’s commercial processor giants such as Intel, ARM and Imagination Technologies.