ABV and people from Missouri...

ABV and people from Missouri...

The last industry project I worked on, before joining EDA, was an advanced chip set for a very large, high-end server product line. The project consisted of a large team, spanning multiple years, with numerous physical, design, and verification challenges. During the project’s postmortem, where all the various engineering teams get together to discuss what worked well and what did not, I overhead one of the design engineers say that he would never do another design project without assertions.  In fact, his opinion was universally shared among all the project designers. Now, wait a minute, notice I said designers. What gives?  When questioning the design team further, I heard them say that assertions actually made their life easier.  The team claimed that the extra time it took them to add assertions during the RTL coding stage was more than made up for by the reduction in debugging time during verification. Not only that, they claimed that often the act of adding an assertion forced them to think about the design in a different way and even exposed a design error prior to any form of verification. Now that’s productivity!

All right, so if this stuff is so great, then why isn’t everyone doing it? In fact, a large industry study conducted by Farwest Research in conjunction with Mentor Graphics late in 2007 revealed that only 37 percent of the industry had adopted and integrated ABV techniques into their flow. This intrigues me—particularly since there have been numerous case studies published by best in class companies over the past 15 years that quantitatively demonstrate the benefits of adopting ABV into the project flow.  So I decided to dig a little deeper into this situation, and this is what I found:

1. Project teams need help in understanding the methodological aspects of integrating ABV into their existing flow.
2. There are a number of myths held by non-believers that need to be addressed before adoption can proceed.

If you look at the myriad of material that has been published on ABV over the past few years, what you will find is that most of the discussions focus on value propositions and specific ABV tools, or the discussion delves into details of a particular assertion language.  However, what I hear from various teams trying to adopt ABV often takes a more methodological bent, particularly related to the required steps for successfully integrating ABV into existing flows.

To address these concerns, at DAC 2008, with the sponsorship of Accellera, I organized a successful workshop titled: Beyond Syntax and Semantics: Industry Experiences with OVL/SVA/PSL.

I recognized that successful application of these assertion language standards in an industrial setting requires the development of project team member skills and verification process maturity beyond a simple understanding of assertion language syntax and semantics. Hence, the workshop was organized so that folks from multiple industry projects would share their experiences of applying ABV on real projects—with a focus on answering these questions:

• What is required to mature a project team’s ABV skills for successful adoption?
• What needs to be considered in terms of a project’s ABV infrastructure (beyond commercial tools)?
• What metrics need to be defined (and gathered) to measure progress?
• What benefits are real-industry projects seeing using OVL/SVA/PSL?

Going forward, what I plan to do in the next few weeks is create a set of related blogs where I address both the methodology aspects of integrating ABV into a project flow and a number of commonly held myths about ABV.

I’d like to hear from you.  Who has successfully integrated ABV into the flow?  For those who have not started, what are the obstacles you see to adoption?

More Blog Posts