Assertion-based verification has many advantages, but is not particularly easy to use. At Silicon Valley DVClub April 26, two engineers discussed the benefits and challenges of assertions, and described their experience with two tools that help answer the question, "who's going to write all those assertions?"
DVClub (Design Verification Club), co-sponsored by Cadence, presents free educational and networking events at various locations in the U.S., Europe, and India. Presenters at the Silicon Valley DVClub luncheon were Jing Li, verification engineer at Broadcom, and Eric Deal, president of silicon IP provider Cyclic Design.
Li described Broadcom's experience with BugScope, an "assertion synthesis" tool from NextOp Software, while Deal described his experience with Zazz, a tool from Zocalo that helps users create and debug SystemVerilog assertions. (Both companies are Cadence partners and both tools are closely integrated with the Cadence Incisive simulation environment. Last year I ran Industry Insights Q&A interviews with Yunshan Zhu, CEO of NextOp, and Howard Martin, president of Zocalo).
Broadcom: Challenges of Assertions
Li described a "traditional" verification flow at Broadcom that includes block-level testing, coverage signoff, subsystem testing, chip-level testing, and emulation. While this flow has been quite successful, she noted that "as design complexity increases, we're finding bugs later than what we'd like to see. It's an indication we need to improve the methodology so that at each level of verification, we have more visibility into what is being tested."
Assertion-based verification (ABV) can provide that visibility, but has not been part of the Broadcom flow because "we have some issues that couldn't be solved." Li identified the following problems:
- Learning the SystemVerilog assertion (SVA) language and mastering assertion coding is difficult for engineers
- Assertions are time-consuming to debug
- Assertions may not directly match designer intent, resulting in false failures in simulation
- There's no good way to measure the quality of hand-generated assertions
- It's unclear how many assertions one needs to write
- Assertion reuse is a problem, with new assertions often needed even for small design changes
These challenges led Broadcom to evaluate BugScope. Li described how it automatically generates assertions based on regressions, and how designers then evaluate assertions to determine which are "true" assertions and which are functional coverage properties.
"We found that using this assertion synthesis technology helps improve the quality of block-level verification," Li said. "For almost every block for which we tried BugScope, we were able to find bugs, and most of those bugs could not be found with the old flow. And we were able to find bugs even during the property review process." All this is possible with very little change to the existing verification flow, she said.
Li provided four examples of bugs found with BugScope that would not have been detected without assertion synthesis. She described a bug that was found without running any tests at all, a bug hiding in a functional coverage hole, a bug that was not detected with manually generated assertions, and a bug that appeared only in emulation and could not be replicated with simulation or formal verification.
However, she also listed some improvements Broadcom would like to see, including generation of assertions for cross-module bugs, a GUI for the assertion classification process, and better performance with large numbers of instances. BugScope, she concluded, is "now officially part of our signoff criteria and is really increasing our verification confidence."
Cyclic Design: Assertions for IP Verification
Eric Deal brought a different perspective to the DVClub meeting - he's a designer, and he's president of a company that specializes in error correction (ECC) IP for NAND flash. He's long been a believer in ABV, and he noted a number of advantages of assertions. He said they can cut debug time, improve designer-to-verification engineer communications, document design behavior, detect unobservable faults, and ease integration of IP modules. On this last point, he said that assertions "really provide a lot of added value to my customers."
Deal started using the Open Verification Library (OVL) some years ago when it was being standardized by Accellera. While easy to use, the assertions are simple and inflexible, and result in "messy" code when they get instantiated into modules. Then he learned SVA, and found that it provided more power and flexibility. However, he noted, it's difficult to construct "anything beyond relatively simple assertions" with SVA.
Approached by a founder of Zocalo, Deal evaluated an early version of Zazz. The product has two big advantages, he said. First, its graphical Visual SVA environment makes it possible to create complex assertions without becoming an expert in SVA syntax. Secondly, and perhaps most importantly, Zazz provides a way to debug assertions at the time of creation. It does this by effectively creating a constrained-random testbench around each assertion, and generating a pass or fail waveform.
The impact on Cyclic Design? "It improved my internal verification and debug time by quickly identifying both the time and location of errors in simulation," Deal said. Today the company ships assertions with its IP. The assertions help customers find problems in ports and interfaces, and provide insights not covered in the user's guide. But customers must be educated to turn the assertions on.
Assertions are a powerful tool for designers and verification engineers, but writing assertions is a pain. For this reason tools from NextOp and Zocalo have attracted a good deal of interest. There's no better way to learn about them than to hear directly from the users. Thus, I think this DVClub presentation was very timely. See the DVClub web site for information about upcoming presentations in various cities.