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.
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.
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.
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.
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.
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.
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
The truth is out there...sometimes
it's in a blog.
Anu, NextOp is a Connections partner and tests its generated assertions with Incisive Enterprise Simulator, Incisive Formal Verifier and Palladium XP.
I agree with you that in the early days to get started with writing Assertions was to review the waveforms. That is how the validation team in Cadence where I was part of initially started writing the safety properties when ABV was started.
There is a free whitepaper too of Bugscope from NextOp with Verdi from Springsoft at www.nextopsoftware.com/.../NextOp_SpringSoft_WP.pdf.
How does IFV or IEV fare on the automatically generated assertions by NextOp, especially in terms of supporting the synthesized assertions and its performance with IFV/IEV.