Building a Productive Team for New Verification Approaches

Last week I used a talk by Vigyan Singhal, CEO of formal consulting experts Oski Technology, as the springboard for a blog post on how to extend verification planning for formal analysis and graph-based SoC verification. This week, I’m using a panel held at that same “Decoding Formal Club” meeting as the starting point for my thoughts on how to establish an effective team to use relatively new verification technologies such as formal and graphs.

The second half of the meeting was a panel on “How to Build a Productive Formal Team” moderated by Harry Foster from Mentor. The participants included a nice mix of users, while Vigyan rounded out the panel with his unique blend of formal tool development and hands-on usage with many customers. Although there wasn’t much controversy per se, it was clear that everyone had different experiences leading to different opinions on how to build a strong formal team.

The first panelist was Flemming Andersen, Principal Engineer and Formal Verification Manager at Intel. He recommended that the first hire be a “formal expert and leader” who has the responsibility to fill out the rest of the team. He made the scariest comment of the day when he said that the full ramp for a new formal team can take 5-10 years, although he acknowledged that experts such as Oski can do a lot to jump-start the process.

In fact, Joanne Ottney, Director of Engineering, did hire the Oski folks to pioneer the use of formal at Palo Alto Networks. She’s become a believer; formal was used to verify seven sub-modules before tape-out and to track down a post-silicon bug in the full chip. Normando Montecillo, Associate Technical Director for Broadcom DVT, focused on the development of return-on-investment (ROI) analysis for the adoption of formal. He noted that verification teams are already overwhelmed with current tasks and so it’s tough to convince them to try something new.

Prosenjit Chatterjee, Director of Engineering at NVIDIA, also kick-started their first formal project a dozen years ago with consultants from Jasper. Since then they’ve grown their in-house formal team to 21 full-time members. Vigyan also argued for full-time dedicated formal engineers. Other keys to success he mentioned included using formal for sign-off, combining formal coverage with simulation results, and integrating formal into the verification plan.

Da Chuang, Chief Technology Officer of Memoir Systems, presented the most explicit list of recommendations. He said that engineers hired into the formal team must have a computer architecture background, a familiarity with parameterized design styles, and the ability to create abstract reference models. He reported that Memoir looks specifically for engineers with 10-15 years of ASIC design experience and strong understanding of logic synthesis.

I found this last point especially interesting. I built the applications team at formal pioneer 0-In Design Automation nearly from scratch, and had my best results hiring RTL designers who were looking for a role that would get them out of their cubicles more often. I had less success hiring verification applications engineers and teaching them formal because they lacked the architecture and design knowledge required for writing good assertions and developing abstractions.

When the floor was opened for questions, I asked the panel members to summarize their ideal teams. The consensus seemed to be that a few formal PhDs to establish methodologies, a few verification engineers to tie into the simulation world, and a bunch of designers was the best mix. Naturally, I compared this answer to what I’ve observed at our long-term customers who’ve now built teams on multiple projects to support graph-based SoC verification.

The biggest difference I see is that there is very little expertise in the industry on using graphs for verification, and so we had to design our products to be usable by everyday verification engineers. Learning how to specify the graph is really quite easy and no special knowledge is required. I was delighted to see this; my biggest concern on joining Breker was that graphs would be a significant barrier to adoption.

The biggest commonality between formal and graph-based teams is that architects and designers are a natural fit for both. Understanding the design, how it works, and how all the pieces fit together makes specifying assertions, graph-based scenario models, and constraints easier. Among verification engineers, a similar story applies. The more that a user knows about the design being verified, the more natural SoC verification will feel.

Tom A.

The truth is out there … sometimes it’s in a blog.

Tags: Breker, constraints, decoding formal, formal analysis, functional verification, graph, jasper, oski, scenario model, simulation, SoC verification

This entry was posted on Tuesday, May 6th, 2014 at 8:55 pm. 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.