Why Can’t You Write My Assertions for Me? - Part 2

In my last post, I described three different types of automatic assertions: those derived from the design, those derived from the design with some assumptions such as naming conventions, and those derived from the design plus supplemental files expressing some aspect of design intent. I finished by mentioning the approach taken by NextOp, which analyzes simulation traces to "learn" about a design's behavior and generates appropriate assertions (and coverage). I'm intrigued enough by their "assertion synthesis" technology to spend some time discussing it in this follow-up post.

I should note first that the idea of "learning" correct or intended design behavior by analyzing simulation traces is not a new one. In my past experience with assertion-based verification companies and product lines, this notion has been discussed and a few skunk-works projects have been tried. The focus was always on "learning" interface protocols, with the belief that if you watch the behavior on an interface long enough most of the legal protocol will be exercised and, if the design has been verified on a previous project, no illegal behavior will occur.

When I first heard about what NextOp was doing, I figured that their focus would be on input protocols with the goal to generate a set of assertions capturing the protocol rules. As I discussed at a recent DVCon panel, I believe that this capability can be a very important link from simulation to formal analysis. One of the big barriers to formal is the requirement to write input assertions that constrain the analysis to stay in legal state space. After all, hitting a targeted coverage point with an illegal input sequence doesn't qualify as closing a coverage gap. Likewise, triggering an assertion with an illegal input sequence forces the verification team to spend time diagnosing an apparent bug that probably isn't real.

I have little doubt that NextOp can and will add value in the transition from simulation to formal input constraints. However, as I've talked more to the NextOp team and read their material, two important distinctions beyond my assumptions have emerged. First, NextOp seems to be quite successful at generating "white box" assertions internal to the design. This is a very powerful feature for formal analysis, because without assertions to target a formal tool will never find any bugs. Generating both input constraints and internal assertions is a great way to move from simulation into formal.

Second, NextOp generates coverage points as well as assertions. This capability is also powerful since formal analysis can target these coverage points and thereby help close coverage gaps. But the value of the "white box" assertions and covers that NextOp generates doesn't rely on formal being used. Any generated assertions and covers can be run in simulation, in a simulation accelerator, or even within an in-circuit emulator. The white-box assertions are valuable internal checks for design bugs and the covers help to assess how well the design is exercised during the verification process.

I can see why NextOp's customers are excited about their approach. An Altera user report on DeepChip last month last month stated "We added approximately 95% of the 250 generated properties to our simulation." That report impressed me; based on what I've seen in the past I would have expected only half or two-thirds of the synthesized assertions and covers to be worth using. If you want to hear more about their approach, a NextOp user from Broadcom will be presenting at this week's DVClub meeting in Silicon Valley. I strongly encourage you to attend; the DVClub events are always well run and stimulating.

The other presentation at this week's meeting is by Cyclic Design regarding their use of Zocalo's assertion solutions. No matter how successful NextOp may be, there will always be assertions in a designer's head that can't be extracted by an EDA tool, as well as new portions of the design that do not have simulation testbenches available yet. Thus, there will always be a subset of assertions that must be written by the design and verification engineers. Zocalo focuses on making this task easier. I'll discuss their approach in Part 3 of this blog series.

Tom A.

The truth is out there...sometimes it's in a blog.