Get email delivery of the Cadence blog featured here
One of the most exciting recent EDA startups is NextOp Software, provider of the BugScope "assertion synthesis" tool for RTL verification. NextOp is a Cadence Connections partner and is presenting a paper at the upcoming CDNLive! Silicon Valley Oct. 26, 2010. In this interview Yunshan Zhu, co-founder, president and CEO of NextOp, discusses how assertion synthesis works, what its benefits are, and how it works with Cadence verification tools. A related blog post by Joe Hupcey of Cadence includes a video interview with Zhu.
Q: Yunshan, how did NextOp get started?
A: The company was launched in 2006 by three old friends from CMU [Carnegie Mellon University] who had since gone different ways. I have a PhD in computer science from the University of North Carolina, and I spent a year at CMU doing research in verification. After that I came to Silicon Valley and spent 5 years working at Synopsys, leaving at the end of 2005.
One of my co-founders, Yuan Lu [current NextOp CTO], worked for Broadcom. He was doing complex switching verification, and he recognized the value of assertions, but he couldn't get verification engineers or designers to write high-quality assertions. He had to work very hard to manually write assertions himself. He thought that addressing this lack of white-box observability into the design and verification process would help a lot of customers as well. That was the trigger point for starting the company.
Q: What is assertion synthesis and why is it needed?
A: Assertion synthesis is a technology that leverages the testbench as well as the RTL. It automatically generates functional assertions and functional coverage properties. This allows design and verification teams to find corner-case bugs, to identify issues in their test environment, and to improve overall verification observability.
Q: Briefly, how does BugScope assertion synthesis work?
A: The input to the tool includes a database that we collect from the simulation regression as well as the RTL. Given this input, the tool outputs properties in the NextOp format, which is mostly Verilog with two additional operators. These include an operator for logic implication as well as a next-time operator that presents the value of a signal in the next clock cycle.
Once we have properties in the NextOp format, the designer and the verification engineer will review these properties and classify them as either assertions or coverage properties. Then BugScope will take that classification and do the rest - that is, generate the properties in the proper format, which could be SVA [SystemVerilog assertions] or PSL [Property Specification Language].
Q: How does the user distinguish assertions from coverage properties?
A: If a property covers all legal behaviors that should be universally true, then it is an assertion. If it's an artifact of the series of tests you have given to the tool, and it points to something your simulation didn't do, then it's a coverage property. It's either one or the other.
Q: Are all properties useful, or does the user need to sort through them to cull out redundancy?
A: The simple answer is that all properties are useful. Assertion synthesis generates properties that each take a distinct viewpoint of the RTL. It makes sure there are no redundancies with respect to each other and with respect to the RTL code. So from that perspective we prune a lot of the redundant information out.
Q: Do users generally need to edit properties?
A: The tool generates properties in SVA or PSL, both of which are open text format. The user can edit the properties, but in our typical customer flow, they usually just take the BugScope output as is.
Q: Does BugScope generate all assertions needed for verification, and as such, does it replace the need to manually write assertions?
A: What we often see happen is that customers have very limited assertion density. Our tool will typically increase density on average by 10 fold. We then give the user statistics on how well the RTL design has been covered by the NextOp assertions, and we point out signals that don't have assertions covering them. Those are candidates for the user to manually write assertions.
BugScope addresses white-box assertions. Right now, it does not address interface-type end-to-end assertions, but you can get solutions off the shelf for standard bus protocols. We have a mechanism that lets users manually write assertions for those that BugScope does not automatically generate.
Q: How large a design can BugScope handle?
A: BugScope is a full-chip synthesis solution. It takes a divide and conquer approach and generates assertions and coverage points one module at a time. We've taken modules with 100,000 lines of Verilog. BugScope scales linearly with size.
Q: What are the primary benefits of BugScope, compared to manually writing assertions?
A: One is that BugScope gives the designer a fresh perspective in looking at his RTL design. Another is the productivity gain. On the average, it takes an engineer one minute to review a NextOp property. It may take hours to manually write, debug, and maintain an assertion.
Q: How is NextOp working with Cadence, and what Cadence tools does BugScope work with?
A: NextOp has joined the Connections program, and NextOp and Cadence are working with joint customers. We have joint customers using Incisive Enterprise Simulator XL, Specman, Incisive Formal Verifier, and Incisive Enterprise Verifier. We haven't validated Palladium yet but it's on the roadmap.
BugScope needs to run with simulation to generate the properties, and the properties that are synthesized can then be used to drive formal tools.
Q: Finally, what will your CDNLive! paper cover?
A: The title of the paper is "Assertion Synthesis to Drive Simulation, Formal, and Acceleration." It shows that assertion synthesis is a way for users to link together their block-level and system-level simulation environments, and to link simulation with formal verification and acceleration.