Get email delivery of the Cadence blog featured here
It's time to move from the ad-hoc use of simple assertions to a comprehensive assertion-based methodology, according to Howard Martin, president of verification startup Zocalo Tech. This Cadence Connections partner recently released a tool called Zazz that aims to ease that transition. Zazz, which works with Cadence Incisive simulation tools, promises to make assertions easy to create, use, and debug.
In this interview Martin talks about the advantages and current usage of assertions, the difference between an ad-hoc approach and an assertion-based verification methodology, and the capabilities provided by Zazz. For further information, see the Design Automation Conference video interview that my colleague Joe Hupcey III conducted with Zocalo CTO Khalil Shalish.
Q: Howard, can you give us some background about Zocalo?
A: We incorporated in 2006, and our original focus was testbench design and verification planning. We developed our own SystemVerilog elaborator and parser. We also developed technology to keep the verification plan in synch with the testbench. But it looked like kind of a hard sell. It takes a big company to drive something like that.
In 2008 there was significant interest in OVL [Accellera Open Verification Library]. The three major EDA companies had their own assertion libraries, and these were the first attempts to make assertion use easier and more efficient. Using assertions manually was very time-consuming and error prone. Zazz OVL was introduced at DVCon in 2009. We still have that capability, and the present product [Zazz] uses the same infrastructure. The [SystemVerilog] parser and elaborator are now part of the product.
Q: What are the main advantages of assertion-based verification?
A: Assertions are the only way to compactly represent complex behaviors. The assertion represents the intended behavior of the design. In fact, people start doing assertions before the design is even available. Big customers like the linkage between dynamic and formal verification technology. If they populate a design with quality assertions, they almost get a "two fer" because they can use assertions in formal verification.
The industry expects assertions will decrease respins and reduce debug time by 50 percent, and debug is 60 percent of the verification process. So, theoretically, we could decrease verification by 30 percent! The benefits of assertion-based verification have been well documented over the past 10 years. Only the implementation is holding it back.
Q: How many design teams are using assertions today?
A: We're seeing that about 40 percent of projects use assertions, which is not very impressive given the fact that it's been promoted as a major technology for 10 to 12 years. And for the most part, it's ad-hoc use of simple assertions at the block level. There is a big difference between ad-hoc use and assertion-based verification. Assertion-based verification is a methodology that requires the use of assertions in the functional verification cycle, whereas ad-hoc use is at the user's choice, depending on the designer's attitude and skills.
The implementation of assertion-based verification is so open-ended and difficult that only baby steps have been taken. These baby steps have been quite useful, but the industry hasn't even come close to the potential of assertion-based verification.
Q: What's holding assertion-based verification methodologies back?
A: The primary obstacle to using assertion-based verification is the complexity of the language. Also, an assertion is a piece of code, and you don't want to have to debug it in the simulation environment. There is no clean way to debug a complex assertion.
You can force people to learn SVA [SystemVerilog assertions], but it's difficult. Having to code a complex assertion with temporal and concurrent behavior, without being able to visualize it, would be difficult in any language. It's non-intuitive. It takes months of experience to learn it and use the skills. You can see this in formal verification where they hire an expert to write properties. That's not going to happen in the broader market.
Q: What would a systematic approach to assertion-based verification look like?
A: The first step is a decision to require the use of assertions as part of the functional verification process. If that's not required it won't get done. Implementing the methodology is really a challenge, so the objective of Zazz is to significantly reduce the difficulty and the open-ended nature of the technology. We believe Zazz will motivate people to keep using assertion-based verification.
Q: In brief, what does Zazz provide?
A: It defines where to put assertions, allows you to create any level of assertion without learning SVA, and allows you to debug those assertions outside the simulation environment. It also provides automatic management of bind files, lets you control the assertions, turn them on and off individually, and change parameters in them.
Visual SVA provides a graphical approach; you start at the picture level and convert to code. It also provides automatic documentation. We have a migration path for legacy assertions. We automatically change them to a visual representation using the Visual SVA approach.
Q: It seems that Zazz helps users create assertions, but doesn't automatically synthesize assertions. Why is that?
A: The whole purpose of writing assertions is to ensure the design is representative of the designer's intent. If an assertion is automatically created based on the design, by necessity you put them into the verification flow late. That's not to say there is no value in using automatically created assertions. If you have a mature design and a testbench, they are very useful for verification closure, but that's a far cry from assertion-based verification.
Q: IP integration into systems-on-chip is a big part of the EDA360 vision. How does Zazz help?
A: Our market focus is on SoCs and IP. If you miss the market window, you have big losses, so by necessity SoC designers adopt this technology faster. The value proposition for using IP is design reuse. But the time and cost of integration can wipe out all your gains. Populating IP with quality assertions will have a major impact on cost and integration issues.
Q: How does Zazz work with Cadence verification tools?
A: Cadence promotes metric-driven verification, and assertions are a major part of that puzzle. We believe Zazz will play a major part in addressing the assertion issue as related to metric-driven verification. We also support the [Incisive] simulator. We build in links that control assertions from the testbench, and we link to OVM and UVM. There's no requirement to use OVM or UVM, but the links are there.