ABV and being 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:
-
Project teams need help in understanding the methodological aspects of integrating ABV into their existing flow.
-
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?
Comments
Leave a Reply
You must be logged in to post a comment.
>> What are the obstacles you see to adoption?
Major one I hear from RTL folks often is the verbosity associated (as of SystemVerilog 2005) with using OVL-like libraries. Especially existing users of 0-in checkerware are so much pampered by the ease of use and the value it adds – though their management may have the extra $$ as concern – it is hard for them to appreciate the need to type-type-type the “clock, reset” mundane stuff! It was all being “inferred” so far and suddenly come a standard language/implementation such as SVA and that takes them back in history! Refer to AMD’s excellent presentation on OVL TC for a proof! True, the new (very new I must say) “checker” construct along with $inferred* takes care of it (sigh… it lacks $inferred_enable). We cover these in our recently published SVA Handbook 2nd edition (http://www.systemverilog.us/sva_info.html) and also in upcoming DVCon 2010 paper.
Cheers
Srini
http://www.cvcblr.com
Oh, a shameless plug for your new book! 😉 Seriously, congrats on the new publication. Concerning 0-in checkerware…back before I joined EDA, I was one of the earliest users of the technology, and I also liked being pampered by its ease of use. 😉 The 0-in engineering team obviously spent a lot of engineering $$ to develop the technology in such a way that it would be easy to adopt and use. Not only did it abstract away the details of clocks and resets, but also the complexity associated with temporal logics.
The somewhat slow adoption of ABV in the industry is due more to process issues, and less about language features (or lack of). The reality is that there are different stakeholders of ABV requiring each different use models. A one-size-fits-all methodology will not serve all stakeholders. The demands and needs of the designer focusing on low-level implementation assertions are different from those of a verification engineer who is focused on interface protocols or higher-level, end-to-end behaviors. The demands and needs of an IP provider dealing with multiple customer simulation languages and environments are different than an IP consumer. I plan to blog about these specific methodological needs in a set of future blogs.
Thanks for your feedback and I look forward to seeing your upcoming DVCon paper!
Whenever people talk about assertions, and their benefits, they always seem to address the benefits during the verification of the design. However, I find that there is another very important aspect of assertions that really comes into play way before the design verification of the RTL. That aspect is the clarification and specification of the requirements. The SVA/PSL can be written before a single line of RTL is written. The assertions DO clarify the requirements to a level of abstraction higher and clearer than English. The review process of such SVA/PSL code can be a real payoff before an RTL is written. I even see a payoff in adding such requirement properties in a requirement document, along with English. Harry, did you ever address that key point n your papers?
A plug, we demonstrate that concept, by example, in our SVA 2nd Edition book.
ben@SystemVerilog.us
Yes, I have been making this claim for many years related to both verification planning and the creation of assertions (see DAC Panel 2006 http://www.eetimes.com/conf/dac/showArticle.jhtml?articleID=191600034&kc=2443). It turns out that I observed this first hand over 10 years ago on the very same project that I reference in this blog (before there was even SVA or PSL, and we used proprietary assertion languages). I had an engineer walk into my office one day and ask me for help on how to write a certain type of assertion for his design. I then asked the engineer to go to the white board and draw a timing diagram for his block. While he was at the board describing his design a strange look came over his face. He looked at me and said “You know, I’ve got a bug!” It turns out that just by thinking about the design intent in a different way he uncovered a bug. Talk about improved verification efficiency! I’ve said for years that there is no substitute for thinking.
Harry, it’s good to see that someone who worked with me right out of school is now a well known name in EDA. In fact when I started to learn about ABV, the book you co-authored was my first reference.
As you know Zocalo has “bet the farm” on enabling ABV and I’m from Missouri. If I had known we were in a “missionary market” I may not have jumped in so readily. Anyway here we are and we have really tried to get our arms around what’s needed.
What we see is assertion use is on an ad hoc basis primarily by designers. Most designers can write simple one or two cycle assertions and since it for their own use, they are added inline without documentation. The 37% usage that you define most likely reflects ad hoc use.
We know of only a few companies (large ones) that are making a serious effort to implement ABV as a methodology. They appear to be focusing at the designer level and via comments inserted in the RTL related to OVL assertions. The comments then trigger automated software that handles the bind files and documentation…two important housekeeping tasks of ABV. OVL provides a consistent structure that enables the process.
At the verification level the norm for useful assertions is complex temporal SVAs. SVA is a difficult language that the broader base of verification engineers is not proficient in. This level of SVA must also be debugged representing a major effort. We see very little assertion use at the system level even on an ad hoc basis.
Metrics as you point out is a necessity. To even consider a full scale ABV methodology, management needs a continuous assessment of what assertion use is buying them. Also required is a rigid assessment of where assertions will provide the most leverage. Ad hoc use of assertions seems better than nothing, but is it? They may not even be making a dent in the real need.
Zocalo’s White Paper entitled Enabling Assertion Based Verification describes how Zocalo’s Zazz™ product set addresses the preceding issues and how a company or project can incrementally move into ABV on a cost effective basis. Go to http://www.zocalo-tech.com to download the White Paper.
Best regards,
Dave Stevens, Vice President Operations
Zocalo Tech, Inc.